COMMUNICATION PATH CONTROL METHOD FOR DATA NETWORKS 
USING HIGH-SPEED BUSES INTERCONNECTED BY BRIDGES 



BACKGROUND OF THE INVENTION 

5 Field of the Invention 

This invention generally relates to communication path control methods for 
data networks that use high-speed buses for interconnections among devices by means 
of bridges. Particularly, this invention relates to communication path controls for 
data networks that use high-speed IEEE 1394 serial buses (which are exclusively 
10 described in IEEE standard 1394-1995, namely, "IEEE Standard for a High 

Performance Serial Bus", where "IEEE" is an abbreviation for "Institute of Electrical 
and Electronics Engineers") for interconnections among prescribed devices such as 
personal computers and peripherals as well as audio/visual devices by means of 
bridges. 

1 5 Description of the Related Art 

Recently, personal computers are widely spread in households in various 
countries. To cope with an increasing percentage of households or persons owning 
the personal computers and to further improve use rates of the personal computers 
among general people, manufacturers and engineers develop a variety of techniques 

20 with regard to hardware, software and application of the personal computers, 

peripherals and other related devices. Meanwhile, digitalization is generally and 
widely spread among people to frequently purchase so-called "digital devices" such as 
digital video cameras so that digital data are used to represent images, pictures, voices 
and sounds. For this reason, even the general households perform processing of 

25 digital data produced by the digital video cameras on the personal computers, for 
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example. Under such circumstances, various techniques are developed and proposed 
to improve connectibility among personal computers and peripherals such as printers 
and image scanners, so that they are partly actualized for practical use as universal 
serial buses (USB) and EEEE 1394 serial buses. 
5 Now, a description will be given with respect to communications between 

devices connected by way of IEEE 1394 serial buses. For convenience' sake, the 
devices having connectibility with the IEEE 1394 serial buses are called "IEEE 1394 
devices", and the IEEE 1394 serial buses are simply referred to as "buses". 

Normally, when user connects or disconnects an IEEE 1394 device with an 
10 IEEE 1394 serial bus, initialization (namely, "bus reset") is carried out, so that an ID 
number thereof (namely, "physical ID") is automatically allocated to the IEEE 1394 
device. The allocated physical ID is stored in a CSR (Command and Status Register) 
space of the IEEE 1394 device, which is defined by the IEEE 1394 standard. After 
occurrence of the bus reset, communication is inhibited between the IEEE 1394 
1 5 devices until allocation of the physical ID is completed. 

ID numbers are also allocated to various buses, wherein they are referred to as 
bus IDs. If a data network is configured by way of a single bus, its bus ID can be set 
to '3FFh' where a last letter 'h' represents hexadecimal notation. A combination of 
the bus ID and physical ED is called a node ID. Using such a node ID, it is possible to 
20 discriminate types of the IEEE 1394 devices. 

Specific information specifically owned by the IEEE 1394 device is described 
in an address space defined between an address 'FF FF FO 00 04 OOh' and an address 
'FF FF FO 00 07 FFh' within the CSR space of the IEEE 1394 device. Such an 
address space is generally called "configuration ROM", which is configured by various 
25 sections, namely, Bus info block section. Root-directory section, Unit_directory 
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section, root_leaves section and unit leaves section. In the Bus_info_block section, 
64-bit Extended Unique_ID (nornaally called "EUI-64") is described as a specific ID 
of the IEEE 1394 device. The Root_directory section contains module IDs and 
option information, where module IDs designate modules being assigned to the IEEE 
5 1394 device. Information of the configuration ROM realize discrimination of types 
of the IEEE 1394 devices, wherein specific IDs realize distinction between IEEE 1394 
devices belonging to the same type. 

There are provided two methods for communications between IEEE 1394 
devices connected by the IEEE 1394 serial bus, namely, a first method using 

10 asynchronous packets and a second method using stream packets. Concrete examples 
of those methods will be described with reference to Figures 22 and 23 respectively. 

FIG. 22 shows an example of a format of an asynchronous packet, which is 
configured by multiple fields. Herein, a transmission destination bus ID field FlOO 
stores bus IDs which are respectively allocated to buses connected with IEEE 1394 

15 devices each corresponding to a transmission destination. If communication is made 
by a single bus in a data network, the bus ID can be set to '3FFh'. In addition, a 
transmission destination physical ID field FlOl stores physical IDs that are allocated 
to the IEEE 1 394 devices each corresponding to a transmission destination. A tcode 
field F102 stores a value that is defined in advance by the IEEE 1394 standard to 

20 represent a type of the asynchronous packet. A transmission source ID field F103 
stores 16-bit data wherein high-order ten bits represent bus IDs of buses connected 
with IEEE 1394 devices each corresponding to a transmission source while a low- 
order six bits represent physical IDs of the IEEE 1394 devices. Further, a data field 
F104 stores transmission information. 

25 Generally speaking, procedures of communication using asynchronous 
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packets are classified into three types of transactions, namely, read transaction 
provided for the purpose of reading stored content of a CSR space of an IEEE 1394 
device corresponding to a transmission destination, write transaction for the purpose of 
writing data to the IEEE 1394 device and lock transaction. Herein, the read 
5 transaction uses two types of asynchronous packets, namely, a read request packet and 
a read response packet. Similarly, the write transaction uses two types of 
asynchronous packets, namely, a write request packet and a write response packet. In 
addition, the lock transaction uses two types of asynchronous packets, namely, a lock 
request packet and a lock response packet. 

1 0 FIG. 23 shows an example of a format of a stream packet. Before starting 

communication using stream packets, lock transaction is carried out in advance to 
secure a bandwidth and a channel for use in communication. A number of the 
secured channel is stored in a channel field FllO of a stream packet to be transmitted 
to a certain node. Based on the channel number stored in the channel field FllO, the 

15 node makes a decision whether to receive the stream packet or not. In 

communication using stream packets between IEEE 1394 devices interconnected by 
buses, it is necessary to perform prescribed controls on communication paths for 
interconnections between IEEE 1394 devices, as follows: 

In the communication, bandwidths and channels are secured according to 

20 needs, so that numbers of the secured channels are communicated to the IEEE 1394 
devices that transmit and receive the stream packets to establish communication paths 
(or links). At completion of the communication, the secured bandwidths and 
channels are released to disconnect the communication paths. 

Japanese Unexamined Patent Publication No. Hei 1 1-205363 discloses an 

25 example of a conventional communication path control method in which a device 



controller is provided for the purpose of controlling IEEE 1394 devices for performing 
transmission and reception of isochronous stream packets. Herein, the device 
controller is used to establish or disconnect communication paths between the IEEE 
1394 devices which are controlled subjects. 
5 FIG. 24 shows an outline configuration of the conventional device controller. 

Namely, a device controller 100 is configured by a device control block 101, a device 
information management table storage block 102, a serial bus management block 103, 
an IEEE 1394 transaction layer 104, an IEEE 1394 link layer 105 and an IEEE 1394 
physical layer 106. 

10 The device controller 100 is used to control IEEE 1394 devices, having device 

information, which are connected with buses. Prior to controlling the IEEE 1394 
devices, the device information management table storage block 102 stores the device 
information, which is collected from the IEEE 1394 devices, and management 
information for management of communication paths being established between the 

15 IEEE 1394 devices. As examples of the IEEE 1394 devices that perform 

transmission and reception of isochronous streams packets, it is possible to list 
audio/visual devices (or AV devices) that install master plug registers (referred to as 
"MPR") and plug control registers (referred to as "PGR") based on the known standard 
of IEC61883 (where "lEC" represents "International Electrotechnical Commission"). 

20 The PCRs are classified into two types, namely, "output PCR (referred to as "oPCR")" 
used for transmission of packets and "input PRC (referred to as "iPCR")" used for 
reception of packets. 

Figures 25 A and 25B show formats of the aforementioned PCRs. Namely, 
FIG. 25A shows a format for oPCR, while FIG. 25B shows a format for iPCR. 

25 As shown in FIG. 25 A, the oPCR is configured by eight fields which are 
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denoted by reference symbols F120 to F127 respectively. Herein, the field F124 
stores channel numbers over which isochronous stream packets are to be output. The 
field 122 corresponds to a point-to-point connection counter whose value corresponds 
to a number of point-to-point connections being established for the oPCR based on the 
5 IEC61883 standard. If connections being established using the oPCR correspond to 
broadcast connections defined by the IEC61883 standard, a broadcast connection 
counter of the field F 121 is set to ' 1'. 

As shown in FIG. 25B, the iPCR is configured by six fields which are denoted 
by reference symbols F130 to F135 respectively. 

10 The field F134 stores channel numbers over which isochronous stream 

packets are to be received. The field F132 corresponds to a point-to-point connection 
counter whose value corresponds to a number of point-to-point connections being 
established for the iPCR based on the IEC61 883 standard. If connections being 
established using the iPCR correspond to broadcast connections defined by the 

1 5 IEC61 883 standard, a broadcast connection counter of the field F13 1 is set to ' 1'. 

Accessing to each of the fields of the oPCR and iPCR is made using lock 
transaction. Communication paths are established or disconnected in order to 
perform or stop communication using isochronous stream packets between 
audio/visual devices. Accompanied with establishment and disconnection of the 
20 communication paths, it is necessary to adequately set the aforementioned oPCR and 
iPCR. Next, a concrete description will be given with respect to establishment and 
disconnection of communication paths between audio/visual device as well as setting 
of those PCRs. 

FIG. 26 shows conventional procedures for establishment of a point-to-point 
25 connection between audio/visual devices. In order to establish a point-to-point 



connection between the audio/visual devices, a device controller firstly secures a 
bandwidth and a channel from an isochronous resource manager (referred to as 
"IRM") which is connected with a bus based on the IEEE 1394 standard in step SI 00. 
In step SlOl, a decision is made as to whether the device controller succeeds to secure 
5 the bandwidth and channel or not. If the device controller fails to secure the 

bandwidth and channel, in other words, if a decision result of step SI 01 is "NO", a 
flow ends without proceeding to other steps. 

If the device controller succeeds to secure the bandwidth and channel, in other 
words, if a decision result of step SlOl is "YES", the flow proceeds to step SI 02 in 

1 0 which fields are set with respect to an oPCR of a transmitting node for transmitting 
isochronous stream packets and an iPCR of a receiving node for receiving the 
isochronous stream packets. For example, the secured channel number is set to the 
field F124 of the oPCR shown in FIG. 25A and field F134 of the iPCR shown in FIG. 
25B. In addition, the point-to-point counters of the fields F122 and F 132 are both set 

15 to'r. 

When the aforementioned setting process of step SI 02 is performed on the 
oPCR of the transmission node and iPCR of the receiving node, the flow proceeds to 
step S 103 in which a decision is made as to whether the setting is completed 
successfully on the both PCRs or not. If the step S 1 03 determines that the setting is 

20 completed successfully on the both PCRs, in other words, if a decision resuh of step 
SI 03 is "YES", the procedures for establishment of the point-to-point connection are 
ended. If the setting is not completed successfully on the both PCRs, in other words, 
if a decision result of step S103 is "NO", the flow proceeds to step S104 that 
discriminates whether the setting fails on the both PCRs or not. 

25 If the step S 104 determines that the setting fails on the both PCRs, in other 
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words, if a decision result of step SI 04 is "YES", the flow proceeds to step SI 05 to 
perform a release process to release the secured bandwidth and channel, which are 
secured in the foregoing step S 100, on the IRM. Then, the procedures for 
establishment of the point-to-point connection is ended. If the step SI 04 determines 
5 that the setting fails on either the oPCR of the transmitting node or iPCR of the 
receiving node, in other words, if a decision result of step SI 04 is "NO", the flow 
proceeds to step SI 06 to perform a disconnection process to disconnect the point-to- 
point connection. Then, the procedures are ended. 

FIG. 27 shows procedures for addition of a new receiving node in connection 

1 0 with a point-to-point connection which is established in advance. In order to add a 
new receiving node in connection with a point-to-point connection which is 
established in advance, a flow firstly proceeds to step S 110 to obtain a channel number 
which is described in a field F124 (see FIG. 25A) of an oPCR of a transmitting node. 
Then, the flow proceeds to step Sill in which setting is made with respect to an iPCR 

15 of the new receiving note to be added and the oPCR of the transmitting node. Before 
adding the new receiving node, a point-to-point connection counter of a field F 122 of 
the oPCR of the transmitting node is set to a certain value. To respond to addition of 
the new receiving node, such a value of the point-to-point connection counter is 
incremeted by ' 1' . In addition, the channel number which is obtained in the 

20 foregoing step SllO is set to a field F134 of the iPCR of the new receiving node. 
Further, a point-to-point connection counter of a field F 132 of the iPCR of the 
receiving node is set to '1'. 

After completion of the aforementioned step Sill, the flow proceeds to step 
SI 12 in which a decision is made as to whether the setting is completed successfiiUy 

25 with respect to the oPCR of the transmitting node and iPCR of the new receiving node 



or not. If the step SI 12 determines that the setting is completed successfully with 
respect to both of the oPCR of the transmitting node and iPCR of the new receiving 
node, in other words, if a decision result of step SI 12 is "YES", the procedures are 
ended. If a decision result of step S 112 is "NO", the flow proceeds to step S 113 in 
5 which a decision is made as to whether the setting fails on both of the oPCR of the 
transmitting node and iPCR of the new receiving node. If the step S 1 13 determines 
that the setting fails on both of them, in other words, if a decision result of step SI 13 is 
"YES", the procedures are ended. If a decision result of step S 1 1 3 is "NO", namely, 
if the step SI 13 determines that the setting fails on either the oPCR of the transmitting 

10 node or iPCR of the new receiving node, the flow proceeds to step S 1 14 to perform a 
prescribed process. 

Next, details of the step S114 will be described with reference to FIG. 28, 
which shows procedures for disconnection of the point-to-point connection which is 
established. In order to disconnect the point-to-point connection being previously 

1 5 established between the transmitting node and receiving node, a flow proceeds to step 
S 120 to perform re-setting of the oPCR of the transmitting node and iPCR of the 
receiving node. Namely, the point-to-point connection counter of the field F122 (see 
FIG. 25 A) is decremented by ' 1' while the point-to-point connection counter of the 
field F132 (see FIG. 25B) is decremented by '1'. Then, the flow proceeds to step 

20 S 121 in which a decision is made as to whether the point-to-point connection counter 
of the field F122 of the oPCR of the transmitting node is set at '0' or not. If a 
decision result of step S121 is "YES", namely, if the step S121 determines that the 
point-to-point connection counter of the field F 122 of the oPCR of the transmitting 
node is now set to '0', the flow proceeds to step SI 22 to perform a prescribed process. 

25 If a decision result of step S121 is "NO", namely, if the point-to-point connection 
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counter of the field F 122 of the oPCR of the transmitting node is not set at '0', the 
procedures for disconnection of the point-to-point connection are ended. 

Meanwhile, engineers develop and study IEEE 1394 bridges by which 
multiple buses are mutually interconnected together to allow transmission of packets 
5 between different buses. By using the IEEE 1394 bridges, it is possible to increase 
data networks in scale and data transfer efficiency on the basis of the IEEE 1394 
standard. Practically, the IEEE PI 394. 1 committee works on standardization of the 
IEEE 1394 bridges. The IEEE 1394 bridges have multiple portals and internal 
switching structures for exchange of packets between portals, wherein the portals are 

1 0 connected with different buses respectively. 

FIG. 29 shows an outline configuration of an IEEE 1394 bridge. Namely, an 
IEEE 1394 bridge 110 is configured by multiple portals 111a, 111b, 111c and an 
internal switching device 112. The portals 111a, 111b and 111c are respectively 
connected with buses 1 13a, 1 13b and 1 13c. Normally, each of the portals 111a, 11 lb, 

15 111c acts as an IEEE 1394 device on each of the buses 113a, 113b, 113c. When 
receiving packets to be delivered from one bus to another, each portal sends the 
received packets to the internal switching device 112. The internal switching device 
112 passes the packets sent fi-om one portal to another portal which is appropriate. 
Then, the portal receives the packets being passed from the internal switching device 

20 112 and sends them onto its own bus. 

Thus, a data network can be configured using multiple buses which are 
interconnected together by means of the IEEE 1394 bridge 110. Such a data network 
copes with bus reset that occurs on a certain bus within the multiple buses. That is, 
initialization and reallocation of a physical ID is performed only on the bus on which 

25 the bus reset occurs, whereas other buses which are connected together by way of the 
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IEEE 1394 bridge do not recognize occurrence of the bus reset. For this reason, the 
other buses are capable of continuing communications without interruption, regardless 
of occurrence of the bus reset on the bus. 

The IEEE 1394 bridge 110 has a function to select specific packets from 
5 among packets received by a certain portal to transfer them onto a different bus. Next, 
a concrete description will be given with respect to a transfer method of asynchronous 
packet stream based on the IEEE P1394.1 draft standard issued by the IEEE P1394. 1 
committee. 

Upon receipt of an asynchronous packet, the IEEE 1394 bridge 110 extracts a 
10 transmission destination bus ID of a field FlOO shown in FIG. 22. With reference to 

transfer information stored in advance, the IEEE 1394 bridge 110 makes a decision 

whether to output the received asynchronous packet to the internal switching structure. 

As a storing form of the transfer information, it is possible to list a routing map that is 

realized by bit strings of 1023 bits, for example. Setting of the routine map is made 
1 5 such that in order to transfer an asynchronous packet whose field F 1 00 represents the 

transmission destination bus ID is set to 'n', bit n+1 in a high order is set to '1'. 

FIG. 30 shows a routing map for portals of a data network that is configured 

using four networks being interconnected together by means of three IEEE 1394 

bridges, for example. Herein, total 1023 bits are arranged in line, wherein bits 1, 2 
20 and 4 in a high order are all set to ' 1'. FIG. 3 1 shows a format for 

STREAM_CONTROL entry (referred to as "SCR") used for transfer of stream packets. 

Each portal installs maximally sixty four sets of the SCR, each of which is serially 

numbered. 

Suppose that a portal receives stream packets from its own bus over a 
25 prescribed channel with reference to the SCR shown in FIG. 31. Herein, an "sf field 



F 140 is related to determination whether to output the stream packets, which are 
received over the channel whose nunaber is stored in a "channel" field F141, to the 
internal switching device 112 or determination whether to output the stream packets 
onto the own bus connected with the present portal. Herein, former one is called a 
5 listener operation, while latter one is called a talker operation. Namely, if the st field 
F 140 is set to 'Ih' in hexadecimal notation, the listener operation is performed with 
respect to stream packets using the channel whose number is stored in the channel field 
F141 . If it is set to '2h", the talker operation is performed with respect to stream 
packets being passed from the internal switching device 112. Incidentally, setting of 

1 0 the SCR is invalidated when the st field F 140 is set to 'Oh'. 

Suppose that a portal receives stream packets from its own bus connected 
thereto. The channel field F141 stores a channel number used by stream packets 
which should be transferred to a different bus within the stream packets received from 
the own bus of the portal. Suppose that a portal sends stream packets, being passed 

15 thereto fi-om the internal switching device 112, onto its own bus connected thereto. 

In that case, the channel field F141 stores a channel number which is to be described in 
the channel field FllO (see FIG. 23) of the stream packet. An i field F141 represents 
whether stream packets to be transferred correspond to isochronous stream packets or 
asynchronous stream packets. 

20 When a portal receives a stream packet fi-om its own bus connected thereto, it 

extracts a value described in a channel field Fl 10 of the received stream packet. The 
extracted value is checked with reference to all of SCRs installed in the portal. For 
example, if an st field F 141 is set to 'Ih' so that there exists an SCR in which a 
channel field F 141 is set to the extracted value, the portal performs a listener operation 

25 to output the received stream packet to the internal switching device 112. Suppose 
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that the channel number is set to 'n' (where "n" is a natural number arbitrarily 
selected), which designates an SCR[n] within all SCRs installed in each portal. 
Accompanied with the aforementioned listener operation, the internal switching device 
112 selects an appropriate portal to which the stream packet input thereto is being 
5 transferred. So, the selected portal receives from the internal switching device 112 
the stream packet to correspondingly refer to an SCR[n] that has a same number of the 
SCR of the foregoing portal originally receiving the stream packet from its own bus. 
For example, if an st field F140 of the SCR[n] is set to '2h' indicating a talker 
operation, a value described in a channel field F141 of the SCR[n] is set in the field 
10 Fl 10 of the stream packet being transferred from the internal switching device 112. 
Then, the selected portal transmits the stream packet onto its own bus connected 
thereto. 

By the way, there is a problem in that the conventional communication path 
control method cannot be applied to data networks which are configured using 

15 multiple buses being mutually interconnected by means of IEEE 1394 bridges. 
Reasons will be described below. 

That is, the conventional communication path control method lacks 
procedures for examination (or checking) of buses which are used as communication 
paths being established between IEEE 1394 devices. In addition, the conventional 

20 communication path control method also lacks procedures for securing and releasing 
resources of other buses which differ from own buses specifically connected to the 
IEEE 1394 devices. Further, the conventional communication path control method is 
incapable of detecting bus resets on different buses which differ from the own bus 
specifically connected to the IEEE 1394 devices. Furthermore, it is incapable of 

25 detecting variations of topology. 
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SUMMARY OF THE INVENTION 
It is an object of the invention to provide a communication path control 
method that enables serial bidirectional communication using packets by way of high- 
5 speed IEEE 1394 serial buses. 

It is another object of the invention to provide a communication path control 
method applicable to data networks that are configured using buses, which are capable 
of connecting together multiple IEEE 1394 devices such as audio/visual devices and 
which are mutually interconnected together by means of bridges. Concretely 
10 speaking, this invention provides a communication path control method, a device 

controller and a bridge which are applied to a data network to allow establishment and 
disconnection of communication paths between the IEEE 1394 devices as well as re- 
establishment of communication paths in response to bus resets. 

Namely, this invention provides a communication path control system for use 
15 in a data network which is configured by a number of buses each of which installs at 
least one node as an isochronous resource manager (IRM) based on the IEEE 1394 
standard. Adjacent buses are interconnected together by means of a bridge that 
consists of at least two portals for interconnection. Each portal has a connection 
counter for counting a number of receiving nodes each of which receives stream 
20 packets being transmitted thereto from a transmitting node by way of each portal by 
itself At least one device controller (namely, an IEEE 1394 device) is provided for 
use in establishment and disconnection of communication paths and is connected with 
one of the buses in the data network. For establishment of a communication path 
extending from the transmitting node to a specific receiving node in the data network, 
25 the device controller specifies all portals that lie in the communication path to request 
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each of them to increment a value of the connection counter by T . For 
disconnection of the communication path, the device controller requests each of the 
specified portals to decrement a value of the connection counter by ' 1'. More 
specifically, each of the portals stores a communication path management table 
5 containing the connection counter whose value is incremented or decremented to 
establish or disconnect the communication path. In addition, the device controller 
stores a communication path management table that describes resources in connection 
with a connection counter with respect to each of buses that construct parts of the 
communication path being established, so that the device controller proceeds to 
1 0 establishment of a new communication path by increasing the connection counter or 
the device controller proceeds to disconnection of the communication path by 
decreasing the connection counter Incidentally, the resources describe at least a 
bandwidth and a channel number being used for communication over the 
communication path. 

1 5 At occurrence of bus reset on a specific bus within the buses corresponding to 

the communication path, a specific portal connected with the specific bus proceeds to 
initialization of the specific bus. Then, the device controller proceeds to re- 
securement of the resources which are previously secured before occurrence of the bus 
reset if the transmitting node and receiving node remain being connected in the data 

20 network after occurrence of the bus reset. If the transmitting node or receiving node 
is disconnected from the data network after occurrence of the bus reset, the device 
controller proceeds to disconnection of the communication path. 

BRIEF DESCRIPTION OF THE DRAWINGS 
25 These and other objects, aspects and embodiments of the present invention 
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will be described in more detail with reference to the following drawing figures, of 
which: 

FIG. 1 is a block diagram showing a configuration of a data network that is 
configured using four buses being interconnected together by means of three bridges in 
5 accordance with a preferred embodiment of the invention; 

FIG. 2 is a block diagram showing an internal configuration of an IEEE 1394 
bridge used for interconnection between the buses shown in FIG. 1 in accordance with 
a first embodiment of the invention; 

FIG. 3 shows an example of a content of a communication path management 
] 0 table for one stream of packets, which is stored in a talker portal for sending stream 
packets and a representative portal for receiving instructions regarding establishment 
and disconnection of a communication path; 

FIG. 4 shows an example of a content of a communication path management 
table for one stream of packets, which is stored in a listener portal for receiving stream 
15 packets; 

FIG. 5 shows an example of a format of a command used for request and 
response between an IEEE 1394 device and a portal; 

FIG. 6 shows a concrete example of a request command that is transmitted 
from the IEEE 1394 device to the portal; 
20 FIG. 7 is a flowchart showing a first part of a portal process for establishment 

of communication paths using portals between IEEE 1394 devices via different buses; 

FIG. 8 is a flowchart showing a second part of the portal process for 
establishment of communication paths; 

FIG. 9 is a flowchart showing a third part of the portal process for 
25 establishment of communication paths; 
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FIG. 1 0 shows a concrete example of a response command that the portal 
transmits to the IEEE 1394 device; 

FIG. 11 is a flowchart showing a first part of a portal process for 
disconnection of communication paths using portals between IEEE 1394 devices via 
5 different buses; 

FIG. 12 is a flowchart showing a second part of the portal process for 
disconnection of communication paths; 

FIG. 13 is a flowchart showing a third part of the portal process for 
disconnection of communication paths; 
10 FIG. 14A is flowchart showing a first part of a portal process being executed 

by a portal 7a to cope with a failure of re-securement of a bandwidth or channel after 
occurrence of bus reset; 

FIG. 14B is a flowchart showing a second pard of the portal process being 
executed by the portal 7a; 
1 5 FIG. 15 A is a flowchart showing a portal process being executed by a portal 

7b to cope with a failure of re-securement of a bandwidth or channel after occurrence 
of bus reset; 

FIG. 15B is a flowchart showing a portal process being executed by each of 
portals 8 a, 9a to cope with a failure of re-securement of a bandwidth or channel after 
20 occurrence of bus reset; 

FIG. 16 is a flowchart showing a portal process being executed by each of 
portals 8b, 9b to cope with a failure of re-securement of a bandwidth or channel after 
bus reset; 

FIG. 17 is a block diagram showing an internal configuration of an IEEE 1394 
25 device that proceeds to establishment of communication paths in accordance with a 
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second embodiment of the invention; 

FIG. 18 shows a concrete example of a communication path management 
table being stored in the IEEE 1394 device shown in FIG. 17; 

FIG. 19 is a flowchart showing a first part of a portal process for obtainment 
of path information; 

FIG. 20 is a flowchart showing a second part of the portal process for 
obtainment of path information; 

FIG. 2 1 shows an example of a communication path management table whose 
content is being updated; 

FIG. 22 shows an example of a format of an asynchronous packet; 

FIG. 23 shows an example of a format of a stream packet; 

FIG. 24 is a block diagram showing an outline configuration of a device 
controller conventionally employed in a data network using an IEEE 1394 serial bus; 

FIG. 25A shows a format of an output plug control register (oPCR); 

FIG. 25B shows a format of an input plug control register (iPCR); 

FIG. 26 is a flowchart showing procedures for establishment of a point-to- 
point connection between IEEE- 13 94 devices based on the IEEE 1394 standard; 

FIG. 27 is a flowchart showing procedures for addition of a new receiving 
node in connection with a point-to-point connection which is established in advance; 

FIG. 28 is a flowchart showing procedures for disconnection of the point-to- 
point connection which is previously established; 

FIG. 29 is a block diagram showing an outline configuration of an IEEE 1394 

bridge; 

FIG. 30 shows an example of a routing map for portals in a data network that 
is configured using four networks being interconnected by means of three IEEE 1394 
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bridges; and 

FIG. 3 1 shows a format for STREAM CONTROL entry (SCR) used for 
transfer of stream packets. 



5 DESCRIPTION OF THE PREFERRED EMBODIMENTS 

This invention will be described in further detail by way of examples with 
reference to the accompanying drawings. 

FIG. 1 shows a configuration of a data network that is configured using four 
buses la to Id which are interconnected together by means of three IEEE 1394 bridges 

10 2a to 2c each having two portals in accordance with a preferred embodiment of the 

invention. That is, the buses la and lb are interconnected together by the IEEE 1394 
bridge 2a; the buses lb and Ic are interconnected together by the IEEE 1394 bridge 
2b; the buses lb and Id are interconnected together by the IEEE 1394 bridge 2c. 

In FIG. 1, each of the buses la- Id is configured using multiple IEEE 1394 

1 5 devices in topology. Namely, three IEEE 1394 devices 3a, 3b, 3c are configured on 
the bus la; three IEEE 1394 devices 4a, 4b, 4c are configured on the bus lb; four IEEE 
1394 devices 5a, 5b, 5c, 5d are configured on the bus Ic; two IEEE 1394 devices 6a, 
6b are configured on the bus Id. In addition, the IEEE 1394 bridge 2a installs portals 
7a, 7b; the IEEE 1394 bridge 2b installs portals 8a, 8b; the IEEE 1394 bridge 2c 

20 installs portals 9a, 9b. Each of the portals 7a, 7b, 8a, 8b, 9a, 9b has a routing map as 
shown in FIG. 30. For a concrete description of a connection management method of 
the present embodiment, the IEEE 1394 device 5d connected on the bus Ic acts as a 
device controller as shown in FIG. 24. That is, the IEEE 1394 device 5d acts as a 
node for performing management of communication paths between the IEEE 1394 

25 devices with reference to device information data collected from the IEEE 1394 
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devices connected together in the data network. In addition, all of the IEEE 1394 
devices 3a-3c, 4a-4c, 5a-5d and 6a install PCRs (namely, plug control registers). 
[A] First Embodiment 

Now, a first embodiment of this invention will be described in conjunction 
5 with some drawings. In the first embodiment, a communication path management 
table is provided for every stream to be transferred via each of the portals 7a, 7b, 8a, 
8b, 9a, 9b. 

FIG. 2 shows an internal configuration of the IEEE 1394 bridge 2a. The 
other IEEE 1394 bridges 2b, 2c have the same internal configuration of the IEEE 1394 
1 0 bridge 2a, hence, the detailed description thereof will be omitted. In FIG. 2, the IEEE 
1394 bridge 2a is configured using an internal switching structure 10 that interconnects 
together the portals 7a, 7b. The portal 7a is configured by a command control block 
11, a communication path management table storage block 12, an IEEE 1394 
transaction layer 13, an IEEE 1394 link layer 14, an IEEE 1394 physical layer 15 and a 
1 5 serial bus management block 16. The communication path management table storage 
block 12 provides plural communication path management tables 17a to 17n, which 
contain connection counters 1 8a to 1 8n respectively. 

As similar to the portal 7a, the portal 7b is configured by a command control 
block 21, a communication path management table storage block 22, an IEEE 1394 
20 transaction layer 23, an IEEE 1394 link layer 24, an IEEE 1394 physical layer 25 and a 
serial bus management block 26. The communication path management table storage 
block 22 provides plural communication path management tables 27a to 27n, which 
contain connection counters 28a to 28n respectively. 

FIG. 3 shows a concrete example of a communication path management table 
25 for one stream of packets. Namely, such a communication path management table is 
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stored in a "talker portal" that sends stream packets onto its own bus and a 
"representative portal" that receives instructions regarding establishment and 
disconnection of a communication path from a prescribed IEEE 1394 device. In FIG. 
3, a transmitting bus field Fl describes a bus ID of a bus connected with a transmitting 
5 node that transmits stream packets. An EUI-64 field FA2 describes EUI-64 
information of the transmitting node. An oPCR number field FA3 describes a 
number of an oPCR by which the transmitting node transmits stream packets. 

A connection counter field FA4 describes a number of receiving nodes each of 
which receives from the transmitting node, specified by the EUI-64 information 

1 0 described in the EUI-64 field FA2, the stream packets using the oPCR whose number 
is described in the oPCR number field FA3 by way of the portal. A controller field 
FAS describes an node ID of an IEEE 1394 device that firstly requests establishment of 
a communication path. 

A bandwidth field FA6 describes bandwidths being secured for 

15 communication. A channel number field FAT describes channel numbers being 

secured for communication. An SCR number field FAS describes numbers of SCRs 
corresponding to the channel numbers described in the channel number field FA7. 
The table also contains a number of listener portal fields FA9, each of which describes 
a physical ID of a portal that receives stream packets on a certain bus to transfer them 

20 onto an adjacent bus. 

FIG. 4 shows a concrete example of a communication path management table 
for one stream of packets, which is stored in a listener portal receiving stream packets 
from its own bus connected thereto. In FIG. 4, a talker portal field FB5 describes a 
physical ID of a portal that receives stream packets to transmit them onto a bus. An 

25 SCR number field FB6 describes a number of an SCR that is used when a portal 
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receives stream packets to pass them to an adjacent portal. An EUI-64 field FBI 
describes EUI-64 information of a transmitting node. An oPCR number field FB2 
describes a number of an oPCR by which the transmitting node transmits stream 
packets. A channel number field FB3 describes a number of a channel over which 
5 stream packets are to be received. 

[Establishment of Communication Path] 

[Examination of Path Information, Securement of Bandwidth and Channel] 
Next, a concrete description will be given with respect to processes in which 
the IEEE 1394 device 5d proceeds to establishment of a communication path between 
] 0 the IEEE 1394 devices 3b and 6b. Herein, the IEEE 1394 device 3b acts as a 
transmitting node, while the IEEE 1394 device 6b acts as a receiving node that 
receives isochronous stream packets. 

With reference to device information which is collected prior to establishment 
of a communication path, the IEEE 1394 device 5d selects the portal 7a connected 
1 5 with a transmitting bus la of the transmitting node as a representative portal. 

Through examination on paths that lead the portal 7a to a receiving bus Id of the 
receiving node, the IEEE 1394 device 5d issues a request to secure a bandwidth and a 
channel for communication. Concretely, the IEEE 1394 device 5d requests to 
increment an value of the connection counter field FB4 of the aforementioned 
20 communication path management table (see FIG. 4) by ' 1'. Specifically, prescribed 
commands are used for the above request, which will be described below. 

In general, request commands are used for the purpose of making requests on 
IEEE 1394 devices or portals, while response commands are used for the purpose of 
making responses against received requests. Transmission of the request commands 
25 and response commands is realized by write transaction on a command area which is 



23 

secured in advance in a CSR (namely, command and status register) space. To cope 
with the request commands and response commands, it is necessary to secure the 
command area in advance. The IEEE 1394 devices or portals that receive request 
commands and response commands obtain contents of the requests and response 
information by reading out written contents of the command area. 

FIG. 5 shows an example of a format of the aforementioned command, which 
is configured by plural fields FCl to FC19. Within those fields, a tcode field FC5 
describes a value representing a write request, and a transmission destination offset 
field FC8 describes a top address of a command area which is secured in a CSR space. 

In addition, a ctype field FCl 3 describes a command type. Namely, the 
ctype field FCl 3 describes ' Ih' for representation of a request command, while it 
describes 'Oh' for representation of a response command. A rcode field FCl 4 is used 
by the response command only. There are provided several types of response 
commands, which are classified in response to various values described in the rcode 
field FC14 in hexadecimal notation, as follows: 

'8h' : NOT IMPLEMENTED (namely, a node receiving a request command does 

not support a requested process). 

'9h': ACCEPTED (namely, a requested process is completed). 

'Ah': REJECTED (namely, a requested process is not completed). 

'Bh'; INTERIM (namely, a request is accepted so that a requested process is now 

under progress). 

Thus, each of the response commands is named and designated in response to 
each of the aforementioned values described in the rcode field FCl 4. That is, a 
"response command NOT IMPLEMENTED" is designated in response to '8h' being 
set in the rcode field FC 14. Similarly, a "response command ACCEPTED" is 
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designated in response to '9h', a "response command REJECTED" is designated in 
response to 'Ah', and a "response command INTERIM" is designated in response to 
'Bh'. Incidentally, the IEEE 1394 device that transmits a response command 
INTERIM transmits another response command again after completion of a requested 
5 process. 

In FIG. 5, a cl field FC15 describes a command label for discrimination of a 
command. Therefore, a request command and its corresponding response command 
should match with each other with regard to a value of the cl field FCl 5. An opcode 
field FC16 describes an operation that an IEEE 1394 device receiving a request 

10 command should perform and a status of the IEEE 1394 device that should be 

responded. An operand field FC17 describes information that is needed for execution 
of the operation designated by the opcode field FCl 6 as well as information that is to 
be contained in the response. So, the operand field FCl 7 stores different values in 
response to different commands. An IEEE 1394 device that receives a request 

15 command should transmit a response command ACCEPTED or a response command 
REJECTED later Until the IEEE 1394 device transmits such a response command, 
the IEEE 1394 device stores a value of a cl field FCl 5 and a value of an opcode field 
FCl 6 being set in the received request command as well as a value of a transmission 
source ID field FC7 for a write request packet. 

20 FIG. 6 shows a concrete example of a request command that is transmitted 

from the aforementioned IEEE 1394 device 5d to the portal 7a in FIG. 1. Herein, a 
transmission destination bus ID field FCl is set to 'OOOh' which is a bus ID of the bus 
la connected with the portal 7a. A transmission destination physical ID field FC2 
describes a physical ID of the portal 7a. A tcode field FC5 describes ' Ih' which 

25 represents a write request for a data block based on the IEEE 1394 standard. A 
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transmission source ID field FC7 describes a node ID of the IEEE 1394 device 5d. A 
ctype field FC13 is set to ' Ih' indicating the request command. A cl field FC15 is set 
to ' Ih', for example. An opcode field FC16 is set to a prescribed value indicating 
that the request command requests establishment of a communication path extending 
5 from a transmitting bus to a receiving bus. For example, the opcode field FC16 is set 
to 'Oh'. An operand field FC17 describes various pieces of information, namely, a 
bus ID of the transmitting bus, EUI-64 information of a transmitting node, a number of 
an oPCR to be used, a bus ID '003h' of the receiving bus and a bandwidth to be 
secured. 

10 Figures 7 to 9 show a portal process for establishment of communication 

paths using portals between IEEE 1394 devices via different buses. Namely, a flow 
of Figures 7 to 9 is started upon receipt of a request command fi-om the IEEE 1394 
device 5d. At first, when the portal 7a receives the request command by reading its 
written content fi-om the command area, the portal 7a recognizes from the content of 

15 the received request command that a value of a connection counter field (FA4) of a 

communication path management table (see FIG. 3) is requested to be incremented by 
' r in step SA2 shown in FIG. 7. After recognition, the portal 7a transmits a response 
command INTERIM to the IEEE 1394 device 5d in step SA3. 

FIG. 10 shows a concrete example of the response command that the portal 7a 

20 transmits in the aforementioned step SA3. Herein, a transmission destination bus ID 
field FDl is set to a value of high-order ten bits of the transmission source ID field 
FC7 (see FIG. 6) of the received request command, namely, '002h' representing a bus 
ID of the bus Ic connected with the IEEE 1394 device 5d. In addition, a transmission 
destination physical ID field FD2 is set to a value of low-order six bits of the 

25 transmission source ID field FC7 of the received request command, namely, a physical 
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ID of the IEEE 1394 device 5d. 

A tcode field FD5 describes 'Oli' indicating a wite request for data quadlet 
based on the IEEE 1394 standard. High-order ten bits of a transmission source ID 
field FD7 describe 'OOOh', while low-order six bits describe the physical ID of the 
portal 7a. A ctype field FDIO is set to 'Oh' indicating a response command. A 
rcode field FDll is set to 'Bh' (namely, the request command is accepted so that a 
requested process is now under progress). A cl field FD12 is set to ' Ih' which is set 
in the received request command. 

Upon reception of the response command INTERIM transmitted from the 
portal 7a, the IEEE 1394 device 5d recognizes that the request is accepted by the portal 
7a to wait for a next response command to be sent fi-om the portal 7a. The portal 7a 
checks whether to install a communication path management table being specified by 
the bus ID of the transmitting bus, EUI-64 information of the transmitting node and 
oPCR number which are described in the operand field FC17 (see FIG. 6) in steps SA4 
and SA5 shown in FIG. 7. If a decision result of step SA5 is "NO", namely, if the 
portal 7a does not install the communication path management table therein, the flow 
proceeds to step SA6 in which the portal 7a newly creates a communication path 
management table (see FIG. 3) on which received information is to be described. 
Concretely, the portal 7a describes on the table the bus ID of the transmitting bus, 
EUI-64 information of the transmitting node, oPCR number and bandwidth which are 
described in the operand field FCl 7 of the received request command. In addition, a 
value of a transmission source ID field of a write request packet is described in a 
controller field (FAS). Further, a connection counter field (FA4) is set to ' 1 '. If the 
portal 7a already installs the communication path management table therein, in other 
words, if a decision result of step SA5 is "YES", the flow proceeds to a series of steps 
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starting from step SA39, which will be described later. 

After creation of the new communication path management table in step SA6, 
the flow proceeds to step SA7 in which the portal 7a secures a bandwidth and a 
channel requested by the IEEE 1394 device 3 c which is an IRM (namely, Isochronous 
5 Resource Manager) of the bus 1 a. If the portal 7a succeeds to secure the bandwidth 
and channel, the portal 7a describes a channel number of the secured channel in a 
channel number field (FA7) of the communication path management table created by 
the step S A6. If the portal 7a fails to secure the bandwidth or channel, in other words, 
if a decision resuh of step S A8 is "NO", the flow proceeds to step SA9 in which the 

10 portal 7a transmits a response command REJECTED to the IEEE 1394 device (or 

portal) issuing the request command. In step SAIO, the portal 7a discards the newly 
created communication path management table. Then, the portal 7a ends the portal 
process of FIG. 7. 

If the portal 7a succeeds to secure the bandwidth and channel for 

15 communication, in other words, if a decision result of step SA8 is "YES", the flow 
proceeds to step SAl 1 in which a decision is made as to whether a number of an SCR 
to be set is included in the received request command or not. If the SCR number is 
not included in the request command, namely, if a decision result of step SAll is 
"NO", the portal 7a compares a bus ID of a receiving bus included in the request 

20 command with a bus ID of a specific bus connected thereto in step SA12. If those 
bus IDs match with each other, namely, if a decision resuh of step SA12 is "YES", the 
flow proceeds to step SAl 3 to perform a prescribed process, details of which will be 
described later. If the SCR number is included in the request command, namely, if a 
decision result of step SAll is "YES", the flow proceeds to a series of steps, starting 

25 from step S A50, details of which will be described later. 
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If the portal 7a performs comparison in step SA12 to determine that the bus 
ID of the receiving bus included in the request command does not match with the bus 
ID of an own bus connected to the portal 7a, namely, if a decision result of step SA12 
is "NO", the flow proceeds to step SA14 shown in FIG. 8 in which routing maps are to 
5 be obtained from the portal 7a itself as well as all portals connected with the own bus 
of the portal 7a. In the present situation, the bus la is connected with the portal 7a 
only, hence, the portal 7a reads a routing map stored therein. With reference to the 
routine map, the portal 7a specifies a portal that stores a routing map whose prescribed 
bit corresponding to the bus ID of the receiving bus is set to '1' as a portal that lies in a 

1 0 path extending from the transmitting bus to the receiving bus in step S Al 5 . 

A physical ID of the specified portal is described in a listener portal field of 
the communication path management table. In the routine map of the portal 7a, bit 4 
corresponding to a fourth bit counted from a top bit in a high order is set to T. 
Therefore, the portal 7a recognizes itself as a portal that lies in the path. If the portal 

15 7a fails to specify such a portal that lies in the path, namely, if a decision result of step 
SA16 is "NO", the flow proceeds to step SA17 which is identical to the foregoing step 
SA9, that is, the portal 7a issues a response command REJECTED to the IEEE 1394 
device or portal that issues the request command. Then, the portal 7a releases the 
secured bandwidth and channel while clearing the setting of the SCR. Thereafter, the 

20 flow proceeds to step SAl 8 which is identical to the foregoing step SAIO, that is, the 
portal 7a discards the communication path management table. Thus, the portal 
process is ended. 

If the portal 7a succeeds to specify the portal that lies in the path, namely, if a 
decision result of step SAl 6 is "YES", the portal 7a transmits to the specified portal 
25 that lies in the path a request command requesting the adjacent portal 7b to transmit a 
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request command requesting an increment of a value of a connection counter field by 
' r in step SAl 9. An operand field of such a request command describes the bus ED 
of the transmitting bus, EUI-64 information of the transmitting node, number of the 
SCR being used, node ID of the IEEE 1394 device 5d that proceeds to establishment of 
5 the communication path, bus ID of the receiving bus, bandwidth to be needed for 

communication and channel number secured by the portal 7a. In this case, however, 
no packet is transmitted onto the bus la that constructs a part of the communication 
path. 

After completion of step SAl 9, the flow proceeds to step SA20 shown in FIG. 

10 9 in which the portal 7a receives the request command to read out its content from the 
command area. In step SA21, the portal 7a recognizes that it has been requested to 
transmit a request command that requests the adjacent portal 7b to increment the value 
of the connection counter field by ' 1'. After recognition, the portal 7a sends a 
response command INTERIM to the portal (or IEEE 1394 device) that transmits the 

15 request command in step SA22. When the portal receives the response command 
INTERIM in step SA23, the portal is placed in a standby state to wait for a next 
response command to be transmitted therein in step S A24. In the aforementioned 
case, the portal 7a transmits the request command to itself, hence, the response 
command INTERIM is not transmitted on the bus. 

20 After transmission of the response command INTERIM in step SA22 (see FIG. 

9), the flow proceeds to steps SA25 and SA26. Herein, if the portal 7a does not 
provide a communication path management field being specified by the EUI-64 
information and oPCR number of the transmitting node which are described in the 
operand field of the received request command, namely, if a decision result of step 

25 SA26 is "NO", the flow proceeds to step SA27 in which the portal 7a creates a new 



communication path management table which describes the EUI-64 information and 
oPCR number of the transmitting node contained in the aforementioned operand field 
as well as low-order six bits of a transmission source ID field of a write request packet 
being received in a talker portal field, wherein a connection counter field is set to ' 1'. 
5 Upon creation of the communication path management table, a channel number 

included in the request command is set in an SCR that the portal 7a is capable of using 
by itself in step SA28, that is, the channel number is set for an SCR number. 

If the portal 7a fails to set the SCR number, namely, if a decision result of step 
S A29 is "NO", the flow proceeds to step SA30 which is identical to the foregoing step 

10 SA9 shown in FIG. 7 in which the portal 7a transmits a response command 
REJECTED. Then, the portal 7a refers to the connection counter field of the 
communication path management table. If the connection counter field is not set at 
'0', namely, if a decision result of step SA3 1 is "NO", the portal process is ended. In 
contrast, if the connection counter field is set at '0', namely, if a decision resuh of step 

15 SA3 1 is "YES", the flow proceeds to step SA32 in which the portal 7a clears the 
setting of the SCR specified by the SCR number field of the table. Then, the flow 
proceeds to step SA33 which is identical to the foregoing step SAIO in which the 
portal discards the communication path management table, then, the portal process is 
ended. 

20 If the portal 7a succeeds to set the SCR number, namely, if a decision result of 

step SA29 is "YES", the flow proceeds to step SA34 in which the portal 7a transmits 
to the adjacent portal 7b a request command requesting an increment to a value of a 
connection counter field by ' T. In this case, the operand field describes the bus ID of 
the transmitting bus, EUI-64 information of the transmitting node, number of the 

25 oPCR being used, node ID of the IEEE 1394 device 5d that proceeds to establishment 



of the communication path, bus ID of the receiving bus, bandwidth needed for 
communication, and the SCR number which is set as described above. 

Thus, the portal 7b receives from the portal 7a the aforementioned request 
command to proceed to steps SAl to SA19 shown in Figures 7 and 8. Herein, the 
5 portal 7b proceeds to steps SAl 1 and SAl 9 in a different way as compared with the 
aforementioned portal 7a. That is, in step SAl 1, a channel number secured in the bus 
lb is set to the SCR whose number is included in the request command received by the 
portal 7b and is simultaneously stored in an SCR number field of a communication 
path management table. In step SAl 9, the portal 7b transmits a request command 

10 requesting the portal 9a to transmits a request command that requests its adjacent 
portal 9b to increment a value of a connection counter field by T. 

Thus, the portal 9a receives from the portal 7b the aforementioned request 
command to proceed to steps SA20 to SA34 shown in FIG. 9, in which it transmits a 
request command that requests the adjacent portal 9b to increment the value of the 

15 connection counter field by ' 1'. Then, the portal 9a proceeds to step SA35 which is 
identical to the foregoing steps SA23 and SA24. In addition, the portal 9b receives 
from the portal 9a the aforementioned request command to proceed to steps S A2 to 
SA12 shown in FIG. 7. In this case, the bus ID of the receiving bus matches with the 
bus ID of the portal 9b in step SA12. In step SA13, the portal 9b transmits to the 

20 portal 9a issuing the request command a response command ACCEPTED whose 
operand field describes its own node ID and a channel number that the portal 9b 
secures in the bus Id. Then, the portal process is ended. 

Thus, the portal 9a receives from the portal 9b the aforementioned response 
command in step SA36. In step SA37, the portal 9a makes a decision as to whether 

25 the received response command corresponds to 'ACCEPTED' or not. If the portal 9a 
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receives the response command ACCEPTED from the portal 9b, namely, if a decision 
result of step SA37 is "YES", the portal 9a retransmits the response command 
ACCEPTED to the portal 7b originally issuing the request command in step SA38. 
Specifically, the portal 9a sends the response command ACCEPTED whose operand 
5 field additionally describes its own node ID and a value of a channel number field of a 
communication path management table. After completion of step SA38, the portal 
process is ended. On the other hand, if the received response command does not 
correspond to 'ACCEPTED', namely, if a decision result of step SA37 is "NO", the 
portal 9a proceeds to steps SA30 to SA33, then, the portal process is ended. 

10 The portal 7b receives from the portal 9a the aforementioned response 

command to proceed to steps SA36 and SA37 shown in FIG. 9. If the received 
response command corresponds to 'ACCEPTED' in step SA37, the portal 7b proceeds 
to step SA38 to retransmit the response command ACCEPTED to the portal 7a, then, 
the portal process is ended. If not, the portal 7b proceeds to steps SA32 and SA33, 

15 then, the portal process is ended. 

The portal 7a receives from the portal 7b the aforementioned response 
command to proceed to steps SA35 to SA38 or steps SA35-SA37 and steps SA30- 
SA33. Herein, the portal 7a sends the response command to itself, then, the portal 
process is ended. Then, the portal 7a receiving the response command from itself 

20 proceeds to steps SA35 to SA38 or steps SA35-SA37 and steps SA30-SA33, so that 
the response command is to be transmitted to the IEEE 1394 device 5d, then, the portal 
process is ended. 

The IEEE 1394 device 5d receives from the portal 7a the aforementioned 
response command to recognize that a communication path is certainly established 
25 from the transmitting node to the receiving node. Then, prescribed setting is made on 
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the oPCR of the IEEE 1394 device 3b corresponding to the transmitting node and the 
iPCR of the IEEE 1394 device 6b corresponding to the receiving node. Thus, 
communication using stream packets is started between the IEEE 1394 device 3b and 
the IEEE 1394 device 6b. Herein, the IEEE 1394 device 5d captures from the 
5 received response command ACCEPTED the node IDs of the talker portals and 

listener portals of the buses and the channel numbers secured in the buses, which are 
stored therein. 

[Addition of Receiving Node] 

Next, processes for addition of a new receiving node for receiving stream 

10 packets being transmitted from a transmitting node will be described with reference to 
Figures 7 to 9. Herein, a description will be made with respect to an example in 
which an IEEE 1394 device 5c is newly added as a receiving node during execution of 
communication which is performed between an IEEE 1394 device 3 b and an IEEE 
1394 device 6b by using isochronous stream packets. 

15 In the above, an IEEE 1394 device 5d acts as a device controller that proceeds 

to setting of communication paths, so that it selects a representative portal in advance 
for establishment of communication paths. Now, the IEEE 1394 device 5d transmits 
to such a representative portal a request command requesting establishment of the 
communication path. Concretely speaking, the IEEE 1394 device 5d transmits to a 

20 portal 7a a request command to increment a value of a connection counter field of a 
communication path management table, which is provided for each of portals used in 
the communication path to be established, by ' 1 ' . An operand field of the transmitted 
request command describes a bus ID of a transmitting bus, EUI-64 information and a 
number of a used oPCR of a transmitting node, a bus ID (namely, '002h') of a 

25 receiving bus and a bandwidth to be secured. 
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Upon receipt of the aforementioned request command, the portal 7a proceeds 
to steps SA2 and SA3 shown in FIG. 7. Then, the portal 7a proceeds to steps SA4 
and SA5 in which a decision is made as to whether there is provided a communication 
path management table being specified by the EUI-64 information and oPCR number 
5 of the transmitting node, extracted from the operand field of the request command, or 
not. In this case, a communication path has been already established between the 
IEEE 1394 device 3b and IEEE 1394 device 6b. Therefore, the portal 7a stores the 
corresponding communication path management table therein. 

If it is confirmed in step SA5 that the portal 7a stores the communication path 

10 management table, the flow proceeds to step SA39 in which a value of a connection 
counter field is incremented by ' 1'. After incrementing of the connection counter 
field, the portal 7a proceeds to a series of steps SA12 to SA19 (see FIG. 8), wherein 
the portal 7a is being specified in step SA15. Hence, the present portal transmits to 
the specified portal 7a a request command requesting transmission of a request 

15 command to its adjacent portal (7b) to increment a value of a connection counter field 
by ' 1 ' . Namely, the portal 7a receives such a request command being transmitted 
thereto in step SA19, so that it proceeds to steps SA20 to SA26 shown in FIG. 9. 
Herein, the portal 7a stores the communication path management table being specified 
by the EUI-64 information and oPCR number of the transmitting node which are 

20 extracted from the operand field of the request command. Thus, a decision result of 
step S A26 is "YES", so that the flow proceeds to step SA40 which is identical to step 
SA39 shown in FIG. 7. That is, the portal 7a transmits to the adjacent portal 7b a 
request command that requests an increment to a value of the connection counter field 
by'l'. 

25 Upon receipt of the aforementioned request command, the portal 7b proceeds 
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to steps SA2 to SA5 shown in FIG. 7. At this time, the portal 7b stores a 
communication path management table being specified by the EUI-64 information and 
oPCR number of the transmitting node which are extracted from an operand field of 
the request command. Hence, a decision resuh of step SA5 is "YES", so that the 
5 flow proceeds to step SA39. After completion of the step SA39, the portal 7b 
proceeds to a series of steps SA12 to SA19 (see FIG. 8), in which it transmits to a 
portal 8a a request command requesting transmission of a request command to its 
adjacent portal 8b to increment a value of a connection counter field by '1'. 

Upon receipt of the aforementioned request command transmitted from the 

10 portal 7b, the portal 8a proceeds to steps SA20 to SA26 (see FIG. 9). At this time, 
the portal 8a stores a communication path management table being specified by the 
EUI-64 information and oPCR number of the transmitting node which are extracted 
from an operand field of the request command, hence, a decision result of step SA26 is 
"YES". Thus, the portal 8a proceeds to steps SA40 and SA34. That is, the portal 8a 

15 transmits to its adjacent portal 8b a request command requesting an increment to a 
value of a connection counter field by ' 1'. 

Upon receipt of the aforementioned request command transmitted from the 
portal 8a, the portal 8b proceeds to steps SA2 to SA5 shown in FIG. 7. In this case, 
however, the portal 8b does not store a communication path management table being 

20 specified by the EUI-64 information and oPCR number of the transmitting node which 
are extracted from an operand field of the request command, hence, a decision result of 
step SA5 is "NO". Thus, the portal 8b proceeds to steps SA6 to SA12. In step 
SA12, the bus ID of the receiving bus matches with an bus ID of the own bus of the 
portal 8b, hence, a decision resuh is "YES" so that the flow proceeds to step SA13. 

25 Then, the portal process is ended. 
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In step SA13, the portal 8b transmits a response command ACCEPTED to the 
portal 8a. Upon receipt of such a response command from the portal 8b, the portal 8a 
proceeds to steps SA23, SA24 and a series of steps SA41 to SA49 shown in FIG. 8. 
Herein, step S A45 is identical to the foregoing step SA9 while step SA49 is identical 
5 to the foregoing step SAIO. Then, the procedures which are described before in the 
paragraph named "[Establishment of Communication Path]" are sequentially carried 
out so that a response command ACCEPTED is to be transmitted to the IEEE 1394 
device 5d. Upon receipt of the response command ACCEPTED, the IEEE 1394 
device 5d judges that a communication path is completely established for the IEEE 

10 1394 device 5 c corresponding to a new receiving node to be added, so that setting is 
made on an iPCR of the receiving node. After completion of the setting, the IEEE 
1394 device 5c is capable of receiving isochronous stream packets being transmitted 
thereto from the IEEE 1394 device 3 b corresponding to the transmitting node. 

Incidentally, if it is determined in step SAl 1 that an SCR number is included 

15 in the received request command, namely, if a decision resuh of step SAll is "YES" 
(see FIG. 7), the flow proceeds to step SA50 in which setting is made on an SCR. In 
step SA51, a decision is made as to whether the setting of the SCR is completed 
successfully or not. If the setting is completed successfully, namely, if a decision 
result of step SA5 1 is "YES", the flow proceeds to step SAl 2. In contrast, if a 

20 decision result of step SA51 is "NO", the flow proceeds to steps SA9 and SAIO. 
Then, the portal process is ended. 

[Disconnection of Communication Path] 

Next, processes for disconnection of a communication path which has been 
already established between prescribed nodes will be described with reference to 

25 Figures 7 to 9. Herein, description is made with respect to the data network shown in 



FIG. 1 in which communication paths are established in advance from an IEEE 1394 
device 3b to IEEE 1394 devices 5c and 6b respectively, wherein a communication path 
being established between the IEEE 1394 devices 3b and 5c is to be disconnected. 
At first, an IEEE 1394 device 5d acts as a device controller to transmits a 
5 request command that requests a representative portal 7a of a transmitting bus to 
examine and disconnect a communication path extending to a receiving bus. 
Concretely speaking, it transmits a request command that requests each of portals used 
for the communication path to decrement a value of a connection counter field of a 
communication path management table by '1'. 

10 Figures 1 1 to 13 show a portal process for disconnection of communication 

paths using portals between IEEE 1394 devices via different buses. The portal 
process of FIG. 11 is started upon reception of a request command that a portal 7a 
reads from a command area. That is, the portal 7a reads content of the received 
request command from the command area, so that the portal 7a recognizes a request to 

15 decrement a value of a connection counter field by ' 1' in step SB2. After recognition, 
the portal 7a transmits a response command INTERIM to a transmission source 
(namely, the portal 7a itself) of the request command in step SB3. 

After transmission of the response command INTERIM in step SB3, a flow 
proceeds to step SB4 in which the portal 7a refers to communication path management 

20 tables stored therein. In step SB5, a decision is made as to whether there is provided 
a communication path management table being specified by EUI-64 information and 
an oPCR number of a transmitting node, which are extracted from an operand field of 
the received request command, or not. If the portal 7a stores such a table therein, 
namely, if a decision result of step SB5 is "YES", the flow proceeds to step SB6 in 

25 which the portal 7a decrements a value of the connection counter field by ' 1' . If the 
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portal 7a does not store the table, namely, if a decision result of step SB5 is "NO", the 
flow proceeds to step SB7 in which the portal 7a transmits a response command 
REJECTED, then, the portal process is ended. 

After completion of the aforementioned step SB6, the flow proceeds to step 
SB 8 in which a decision is made as to whether an updated value (namely, a 
decremented value) of the connection counter field is '0' or not. If the updated value 
of the connection counter field is '0', namely, if a decision result of step SB8 is "YES", 
the flow proceeds to step SB9 in which with reference to a bandwidth field and a 
channel number field of the communication path management table, the portal 7a 
releases a bandwidth and a channel that are secured for a communication path to be 
disconnected. In step SB 10, the portal 7a clears setting of an SCR to which the 
released channel number is set. In step SB 11, the portal 7a discards the 
communication path management table. 

In step SB 12, a decision is made as to whether a bus ID of a receiving bus 
matches with a bus ID of an own bus connected with the portal 7a or not. Herein, 
those bus IDs do not match with each other, hence, a decision result of step SB12 is 
"NO" so that the flow proceeds to step SB 13 shown in FIG. 12. In step SB 13, the 
portal 7a obtains routing maps of all other portals connected with its own bus as well 
as a routine map of itself With reference to the routing maps, the portal 7a specifies 
a portal storing a routing map in which a specific bit representing a bus ID of a 
receiving bus is set to ' 1' as a portal that lies in the communication path extending to 
the receiving bus in step SB 14. If the portal 7a fails to specify such a portal, namely, 
if a decision result of step SB 15 is "NO", the flow proceeds to step SB 16 which is 
identical to the foregoing step SB7 shown in FIG. 11, then, the portal process is ended. 

If the portal 7a succeeds to specify the aforementioned portal, namely, if a 
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decision result of step SB 15 is "YES", the flow proceeds to step SB 17 in which the 
portal 7a transmits to the specified portal a request command requesting transmission 
of a request command to its adjacent portal to decrement a value of a connection 
counter field by ' T . In this case, the portal 7a transmits the aforementioned request 
5 command to itself Due to the step SB 1 7, the portal 7a receives the aforementioned 
request command. Then, the flow proceeds to step SB 18 shown in FIG. 13 in which 
the portal 7a reads content of the received request command from the command area. 
In step SB 19, the portal 7a recognizes a request of transmission of a request command 
that requests the adjacent portal 7b to decrement a value of a connection counter field 
10 by'l'. 

After recognition, the portal 7a transmits a response command INTERIM to a 
transmission source (namely, the portal 7a itself) of the aforementioned request 
command in step SB20. After transmission of the response command INTERIM, the 
flow proceeds to step SB21 in which the portal 7a refers to communication path 

15 management tables stored therein. In step SB22, a decision is made as to whether 
there is provided a communication path management table being specified by the EUI- 
64 information and oPCR number of the transmitting node, which are extracted from 
the received request command, or not. If the portal 7a does not store such a table 
therein, namely, if a decision result of step SB22 is "NO", the flow proceeds to step 

20 SB23 in which the portal 7a transmits a response command REJECTED, then, the 

portal process is ended. If the portal 7a stores the table, namely, if a decision resuh of 
step SB22 is "YES", the flow proceeds to step SB24 which is identical to the foregoing 
step SB 6, in which the portal 7a decrements a value of the connection counter field by 
'1'. 

25 In step SB25, a decision is made as to whether an updated value (namely, a 



decremented value) of the connection counter field is '0' or not. If '0', namely, if a 
decision result of step SB25 is "YES", the flow proceeds to step SB26 in which the 
portal 7a clears setting of an SCR. In step SB27, the portal 7a discards the 
communication path management table. Then, the flow proceeds to step SB28 in 
5 which the portal 7a transmits a request command to the adjacent portal 7b to 
decrement a value of the connection counter field by '1'. 

Thus, the portal 7b receives from the portal 7a the aforementioned request 
command requesting a decrement of the value of the connection counter field by T. 
Upon receipt of the request command, the portal 7b proceeds to a series of steps SB2 

10 to SB 15 and step SB 17 which are shown in Figures 11 and 12. Due to step SB 17, the 
portal 8a receives from the portal 7b a request command requesting an adjacent portal 
to decrement a value of a connection counter field by ' 1 '. Upon receipt of such a 
request command, the portal 8a proceeds to steps SB 18 to SB28 shown in FIG. 13. 
Due to step SB28, the portal 8b receives from the portal 8a a request command 

15 requesting a decrement of a value of a connection counter field by ' 1 so that the 

portal 8b proceeds to steps SB2 to SB 12 shown in FIG. 11. In step SB 12, the bus ID 
of the receiving bus matches with an bus ID of a bus connected with the portal 8b, 
hence, the flow proceeds to step SB29 in which the portal 8b transmits a request 
command ACCEPTED. 

20 Upon receipt of the response command, each of the portals 8a, 7b and 7a 

proceeds to steps SB30 to SB34, then, the portal process is ended. Herein, step SB30 
is identical to the foregoing steps S A23 and SA24 shown in FIG. 8, while step SB34 is 
identical to the foregoing step SB7 shown in FIG. 11. If the IEEE 1394 device 5d 
receives from the portal 7a a response command ACCEPTED, the IEEE 1394 device 

25 5d recognizes that disconnection of the communication path is being completed, so 
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that it clears setting of an iPCR of the IEEE 1394 device 5c. In FIG. 12, step SB38 is 
identical to the foregoing step SB29, while step SB39 is identical to the foregoing step 
SB7 shown in FIG. 11. 
[Bus Reset in Bus of Communication Path] 
5 Next, a description will be given with respect to a portal process that is 

executed in response to occurrence of bus reset in a prescribed bus within a 
communication path which is established in advance. Concretely, the description will 
be made with respect to the data network shown in FIG. 1 in which communication 
paths are established in advance between the IEEE 1394 device 3 b and the IEEE 1394 

10 devices 5c and 6b respectively, wherein bus reset occurs on the bus lb. In addition, a 
transmitting node (namely, IEEE 1394 device 3 b) and a receiving node (namely, IEEE 
1394 device 5c or 6b) remain being connected in the data network after the bus reset. 

When the bus reset occurs so that a self-ID process defined by the IEEE 1394 
standard is to be completed, the portal 7b that acts as a talker portal on the bus lb 

15 refers to the communication path management table to re-secure a bandwidth and a 
channel which are secured for the bus lb before occurrence of the bus reset. So, the 
description is made with respect to each of cases regarding different manners of re- 
securement of the bandwidth and charmel. 

(1) First case where the portal 7b succeeds to re-secure the bandwidth and channel. 

20 In this case, the portal 7b makes a communication to the IEEE 1394 device 5d, 

then, the portal process is ended. Upon receipt of the communication, the IEEE 1394 
device 5d discriminates whether the bus regarding occurrence of the bus reset is either 
a transmitting bus or a receiving bus or not. If the bus regarding occurrence of the 
bus reset is either the transmitting bus or receiving bus, it makes setting for an oPCR 

25 of the transmitting node or an iPCR of the receiving node. 
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(2) Second case where the portal 7b succeeds to re-secure the bandwidth and 
channel, however, a re-secured channel number differs from a channel number 
being previously secured before occurrence of the bus reset. 
The portal 7b stores the communication path management table whose listener 
5 field describes physical IDs of "listener" portals, namely, 8a and 9a. In the second 
case, the portal 7b transmits to each of the portals 8a, 9a a request command requesting 
a change of setting of an SCR. An operand field of the request command describes 
EUI-64 information and an oPCR number of the transmitting node described in the 
communication path management table of the portal 7b as well as a new channel 
10 number. 

Thus, each of the portals 8a and 9a receives the aforementioned request 
command whose operand field describes the EUI-64 information and oPCR number of 
the transmitting node, by which a certain transmission path management table is being 
specified. With reference to an SCR number of the specified transmission path 

15 management table, each portal sets the new channel number in a channel number field 
of an SCR corresponding to the SCR number. After completion of setting of the new 
channel number, it transmits a response command ACCEPTED. 

Thus, the portal 7b receives from each of the portals 8a, 9a the 
aforementioned request command ACCEPTED so as to change a previous channel 

20 number being previously set in an SCR thereof with the newly secured channel 

number. Then, the portal 7b communicates the newly secured channel number to the 
IEEE 1394 device 5d whose physical ID is described in a controller field of the 
communication path management table thereof 

On the basis of a content of a transmission source ID field of a received 

25 packet, the IEEE 1394 device 5d detects a bus ID of a bus that is connected with the 



aforementioned portal 7b communicating the newly secured channel number thereto. 
If the detected bus ID is either the transmitting bus or receiving bus, it makes again 
setting for the oPCR of the transmitting node or iPCR of the receiving node. 
(3) Third case where the portal 7b fails to re-secure the bandwidth or channel. 
5 Figures 14 to 16 show processes that prescribed portals execute to cope with a 

failure of re-securement of the bandwidth or channel after bus reset. Herein, the 
portal 7b has a communication path management table whose listener portal field 
describes physical IDs of prescribed listener portals, namely, 8a and 9a. In step SCI 
of FIG. 15, the portal 7b transmits to each prescribed listener portal a request 

1 0 command requesting transmission of a request command that requests its adjacent 
portal to reset a value of a connection counter field to '0'. 

Then, the portal 7b receives a response command INTERIM from the 
prescribed listener portal in step SC2. In step SC3, the portal 7b transmits to the 
prescribed listener portal a request command requesting transmission of a request 

1 5 command that requests its adjacent portal to decrease a value of a connection counter 
field of a talker portal by a designated value. Herein, an operand field of the request 
command describes a bus ID of a transmitting bus as well as EUI-64 information and 
an oPCR number of a transmitting node. In addition, it also describes the value 
which is designated for decrease and is set to a value of a connection counter field of 

20 the transmission path management table being stored in the portal 7b before 
occurrence of the bus reset. 

Then, the portal 7b receives a response command INTERIM fi-om the 
prescribed listener portal in step SC4. Thereafter, the flow proceeds to step SC5 in 
which the portal 7b refers to the communication path management table regarding a 

25 "disconnecting" communication path, which should be disconnected, to reset a value 



44 

of a connection counter field to '0'. In step SC6, the portal 7b receives from each of 
the portals 7a, 8a and 9a a response command ACCEPTED. In step SC7, the portal 
7b communicates result of the process thereof to the IEEE 1394 device 5d, then, the 
portal process of the portal 7b is ended. 
5 Next, a description will be given with respect to a portal process being 

executed by each of the prescribed portals 8a, 9a upon receipt of the aforementioned 
request command from the portal 7b (see step SCI in FIG. 15 A) with reference to FIG. 
15B. In step SC8, each of the portals 8a, 9a reads out content of the request 
command from a command area thereof Thus, each of the portals 8a, 9a recognizes 

10 a request of transmission of a request command that requests its adjacent portal to reset 
a value of a connection counter field to '0' in step SC9. After recognition, the portal 
transmits a response command INTERIM to the portal 7b in step SCIO. Herein, an 
operand field of the received request command describes the EUI-64 information and 
oPCR number of the transmitting node, which are used to specify a certain 

15 transmission path management table. In step SCI 1, the portal resets a value of a 
connection counter field of the specified transmission path management table to '0'. 
Then, the portal performs a series of steps (not shown) which are identical to the 
foregoing steps SA31 to SAB 3 shown in FIG. 9. 

Thereafter, the flow proceeds to step SC12 in which each of the portals 8a, 9a 

20 transmits a request command that requests each of adjacent portals 8b, 9b to reset a 
value of a connection counter table to '0'. In step SC13, each of the portals 8a, 9a 
receives from each of the adjacent portals 8b, 9b a response command INTERIM. In 
step SC14, the portal fiirther receives a response command ACCEPTED from the 
corresponding adjacent portal. In step SCI 5, the portal transmits a response 

25 command ACCEPTED to the corresponding adjacent portal, then, the portal process of 
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the portals 8a, 9a is ended. 

Next, a description will be given with respect to a portal process being 
executed by each of the adjacent portals 8b, 9b upon receipt of the request command 
from the portals 8a, 9a (see step SCI 2 in FIG. 1 5B) with reference to FIG. 16. In step 
5 SC16, each of the adjacent portals 8b, 9b reads content of the request command from a 
command area thereof In step SCI 7, it recognizes a request of resetting a value of a 
connection counter field to '0'. After recognition, each of the adjacent portals 8b, 9b 
transmits to each of the portals 8a, 9a a response command INTERIM in step SCI 8. 
Then, each of the adjacent portals 8b, 9b proceeds to step SC19 which is 

10 identical to the foregoing step SCI shown in FIG. ISA. As for the adjacent portals 8b, 
9b, listener portal fields describe no portals. Hence, the adjacent portals 8b, 9b do not 
transmit request commands therefrom, so they reset values of connection counter fields 
of transmission path management tables thereof to '0' . Then, the flow proceeds to 
step SC20 in which each of the adjacent portals 8b, 9b executes a series of steps (not 

1 5 shown) which are identical to the foregoing steps SB8 to SB 11 shown in FIG. 11. In 
step SC21 in which each of the adjacent portals 8b, 9b executes a series of steps (not 
shown) which are identical to the foregoing steps SCI 3 to SCI 5 shown in FIG. 15B. 
That is, when each of the adjacent portals 8b, 9b receives a response command 
ACCEPTED followed by a response command INTERIM, it transmits a response 

20 command ACCEPTED, then, the portal process of the adjacent portals 8b, 9b is ended. 
Next, a description will be given with respect to a portal process being 
executed by the portal 7a upon receipt of the request command from the portal 7b (see 
step SC3 shown in FIG. 15A) with reference to Figures 14A and 14B. In step SC22 
shown in FIG. 14B, the portal 7a reads out content of the received request command 

25 from a command area thereof In step SC23, the portal 7a recognizes a request of 



46 

transmission of a request command that requests a talker portal to decrease a value of a 
connection counter field by a designated value. After recognition, the portal 7a 
transmits a response command INTERIM to the portal 7b in step SC24. Herein, an 
operand field of the received response command describes the EUI-64 information and 
5 oPCR number of the transmitting node, v^^hich are used to specify a certain 

transmission path management table. In step SC25, the portal 7a decreases a value of 
a connection counter field of the specified transmission path management table by the 
designated value. 

The aforementioned transmission path management table has a talker portal 

10 field that describes the portal 7a by itself In step SC26, the portal 7a transmits to the 
talker portal (namely, the portal 7a itself) a request command that requests decrease of 
the value of the connection counter field by the designated value. Then, the flow 
proceeds to step SC27 in which the portal 7a executes a series of steps (not shown) 
which are identical to the foregoing steps SB25 to SB27 shown in FIG. 13. So, the 

15 portal 7a receives a response command INTERIM in step SC28 and then receives a 
response command ACCEPTED in step SC29. Thereafter, the flow proceeds to step 
SC30 which is identical to the foregoing step SCI 5 shown in FIG. 15B, then, the portal 
process of FIG. 14B is ended. 

Next, a description will be given with respect to a portal process being 

20 executed by the portal 7a to cope with a request command being issued in step SC26 
shown in FIG. 14B with reference to FIG. 14A. In step SC3 1, the portal 7a reads out 
content of the received request command from the command area thereof In step 
SC32, the portal 7a recognizes a request of decreasing a value of a connection counter 
field by a designated value. After recognition, the portal 7a transmits thereto by itself 

25 a response command INTERIM in step SC33. After transmission of the response 
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command LNTERIM, the flow proceeds to step SC34 in which the portal 7a decreases 
the value of the connection counter field of the communication path management table 
being specified by the EUI-64 information and oPCR number, which are extracted 
from an operand field of the request command, by the designated value. Then, the 
5 flow proceeds to step SC35 in which the portal 7a executes a series of steps (not 
shown) which are identical to the foregoing steps SB25 to SB27. In step SC36, 
comparison is made between the bus ID of the transmitting bus contained in the 
request command and the bus ID of the bus connected with the portal 7a itself If 
those buses do not match with each other so that a decision result of step SC36 is 

10 "NO", the flow proceeds to step SC37 which is identical to the foregoing step SC3 
shown in FIG. 15 A, wherein the portal 7a transmits a prescribed request command. 
Then, the flow proceeds to step SC38 which is identical to the foregoing steps SC13 to 
SCI 5, wherein the portal 7a receives prescribed response commands to finally transmit 
a response command ACCEPTED, then, the portal process of FIG. 14A is ended. If 

15 the step SC36 determines that the aforementioned buses match with each other, in 
other words, if a decision result of step SC36 is "YES", the flow directly proceeds to 
step SC38, then, the portal process of FIG. 14A is ended. 
[Measures Against Variations of Topology] 

Normally, prior to controlling of communication paths, the IEEE 1394 device 

20 (namely, 5d) exclusively used for controlling the communication paths transmits to 
prescribed portals connected with buses interconnected therewith request commands 
that request communications when their routing maps are being updated. If a certain 
bus is disconnected from the data network, any one of routing maps of the portals, 
which receive the aforementioned request commands in advance, is to be changed. In 

25 that case, the portal transmits to the IEEE 1394 device that transmits the 
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aforementioned request command a response command whose operand field describes 
a bus ID of the "disconnected" bus. 

Using the aforementioned response command, it is possible to cope with 
variations of topology. That is, the IEEE 1394 device exclusively used for 
5 controlling the communication paths refers to a node ID of the portal being used for 
the communication path so as to specify EIJI-64 information and an oPCR number of a 
transmitting node that uses the disconnected bus as a part of the communication path. 
Then, the IEEE 1394 devices transmits to each of prescribed portals, which are related 
to the specified EUI-64 information and oPCR number of the transmitting node, a 

10 request command that requests reset of a value of a connection counter field to '0'. 
Herein, each of the prescribed portals may corresponds to a talker portal or a listener 
portal. In the case of the talker portal, it proceeds to steps SB8 to SB 11 shown in FIG. 
11. In the case of the listener portal, it proceeds to step SB25 to SB27 shown in FIG. 
13. Thus, disconnection of the communication path is completed. 

15 [Disconnection of IEEE 1394 Device For Controlling Communication Paths] 

A representative portal is selected for establishment of communication paths 
and periodically transmits prescribed packets to the IEEE 1394 device (namely, 5d) 
exclusively used for controlling the communication paths. Concretely speaking, it 
performs read transaction on a NODE_IDS register defined by the IEEE 1394 standard. 

20 Hence, the IEEE 1394 device 5d that exists in the data network performs "packet 
response" for transmitting prescribed packets in response to received packets. 

Suppose that a bus Ic is disconnected from the data network, wherein there 
exists no IEEE 1394 device that responds against packets being transmitted thereto 
from each of portals. Hence, no packet response is made on the portals. If no 

25 packet response is made, the talker portal normally re-transmits the packets several 



times. However, when a number of times of re-transmission of the packets exceeds a 
prescribed number, the talker portal determines that the IEEE 1394 device 5d is 
disconnected from the data network, so it selectively refers to a communication path 
management table whose controller field describes a node ID of the IEEE 1394 device 
5 5d within communication path management tables stored therein. Thus, the talker 
portal proceeds to steps SB8 to SB 11 shown in FIG. 11. Or, the listener portal 
proceeds to steps SB25 to SB27 shown in FIG. 13. Thus, each portal discards the 
communication path management table regarding the IEEE 1394 device 5d, then, the 
portal process is ended. 
10 [Modifications] 

[Measures Against Variations of Topology] 

At completion of establishment of communication paths, the IEEE 1394 
device exclusively used for controlling the communication paths transmits prescribed 
packets to talker portals that construct parts of the communication paths. Concretely 

15 speaking, the IEEE 1394 device performs read transaction on a NODE_IDS register 
defined by the IEEE 1394 standard, wherein the IEEE 1394 device transmits read 
request packets to the portals and waits for responses. If no responses are made 
against the read request packets, the IEEE 1394 device performs re-transmission of the 
read request packets several times. If a number of times of the re-transmission of the 

20 read request packets reaches a prescribed number with respect to a certain portal (or 
certain portals), the IEEE 1394 device determines that a bus connected with such a 
portal is disconnected from the data network. Thus, it is possible to detect variations 
of topology of the data network. 

As described above, the first embodiment is designed such that the portal 

25 secures the bandwidth and channel and makes setting of an SCR, hence, the IEEE 
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1394 device exclusively used for controlling the communication paths does not have to 
recognize the topology of the data network. In addition, the portal does not have to 
restore the communication path in which bus reset occurs on a certain bus. This 
means that a prescribed node for controlling the communication paths does not have to 
5 monitor occurrence of bus reset on a bus that constructs a part of the communication 
path. 

[B] Second Embodiment 

Next, a second embodiment of this invention will be described in detail, 
wherein the second embodiment is designed to secure bandwidths and channels for 

10 buses of communication paths in accordance with different protocols or procedures, 
which will be described below. Different from the first embodiment, the second 
embodiment is designed such that portals do not store communication path 
management tables while only an IEEE 1394 device that proceeds to establishment of 
communication paths stores communication path management tables therein. 

15 FIG. 17 shows an internal configuration of an IEEE 1394 device that proceeds 

to establishment of communication paths in a data network. Namely, the IEEE 1394 
device is configured by a device controller 30, a device information management table 
storage block 31, a serial bus management block 32, an IEEE 1394 transaction layer 33, 
an IEEE 1394 link layer 34, an IEEE 1394 physical layer 35, a command control block 

20 36 and a communication path management table storage block 37. In the 

communication path management table storage block 37, there are provided plural 
communication path management tables 38a to 38n which respectively install 
connection counters 39a to 39n. 

FIG. 18 shows a concrete example of the communication path management 

25 table stored in the IEEE 1394 device. Herein, EUI-64 field FEl describes EUI-64 
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information of a transmitting node. In addition, an oPCR number field FE2 describes 
a number of an oPCR being used by the transmitting node. The communication path 
management table provides plural records Rl to Rn (where "n" is a natural number 
arbitrarily selected), each of which consists of plural fields FES to FES. Namely, 
5 each of the records Rl to Rn installs a bus ID field FES, a portal physical ID field FE4, 
a channel field FES, a connection counter field FE6, a routing field FE7 and an SCR 
number field FES. 

The bus ED field FES describes a bus ID of a "path-constructing" bus that 
constructs a part of a communication path. The portal physical ID field FE4 

10 describes a physical ID of a talker portal that communicates with the path-constructing 
bus. The channel field FES describes a channel number being secured on the path- 
constructing bus by the IEEE 1394 device for establishment of the communication 
path. The connection counter field FE6 describes a number of receiving nodes each 
of which uses the talker portal, being specified by values of the bus ID field FES and 

15 portal physical ID field FE4, as a part of the communication path being established. 

The routine field FE7 describes a node ID of a talker portal of a bus placed adjacent to 
the talker portal being specified by the values of the bus ID field FES and portal 
physical ID field FE4. The SCR number field FES describes a number of an SCR 
that is set by the talker portal specified by the physical ID described in the physical ID 

20 field FE4. 

[Examination of Path Information] 

Suppose that in the data network shown in FIG. 1, the IEEE IS 94 device 5d 
transmits to a portal (e.g., 7a) of a transmitting bus (e.g., la) a request command 
requesting examination on a path-constructing bus. Herein, the request command has 

25 an operand field that designates a bus ID of a receiving bus. Figures 19 and 20 show 
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a portal process for obtainment of path information in the second embodiment of this 
invention. 

The portal process is started upon receipt of the aforementioned request 
command from the IEEE 1394 device 5d. In FIG. 19, a flow firstly proceeds to step 
5 SDl in which a portal 7a reads out content of the received request command from a 
command area thereof In step SD2, the portal 7a recognizes a request of sending 
path information regarding a communication path extending to the receiving bus. 
After recognition, the portal transmits a response command INTERIM to the IEEE 
1394 device 5d in step SD3. Then, examination is made as to whether the bus ID of 

10 the receiving bus matches with a bus ID of an own bus la connected with the portal 7a 
by itself or not in step SD4. At this time, the bus IDs do not match with each other, 
hence, a decision result of step SD4 is "NO". So, the flow proceeds to step SD5 in 
which the portal 7a obtains routing maps from all portals connected with the bus la 
connected therewith. In this case, only the portal 7a is connected with the bus la, so 

15 that the portal 7a obtains a routing map stored therein in step SD5. 

With reference to the routing map, the portal 7a specifies a portal (or portals) 
to which the bus ID of the receiving bus contained in the request command is set in 
step SD6. Next, a decision is made as to whether the portal 7a succeeds to specify 
the portal or not in step SD7. If the portal 7a fails to specify the portal, in other 

20 words, if a decision result of step SD7 is "NO", the portal 7a transmits a response 
command REJECTED to the IEEE 1394 device 5d in step SD8, then, the portal 
process is ended. 

If a decision result of step SD7 is "YES", the portal 7a specifies itself as the 
portal in which the receiving bus is set in the routing map. So, the flow proceeds to 
25 step SD9 in which the portal 7a transmits to the specified portal (namely, portal 7a 
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itself) a request command requesting transmission to its adjacent portal a request 
command for examination of the communication path extending to the receiving bus. 
Then, the flow proceeds to step SDIO shown in FIG. 20 in which the portal 7a reads 
from the command area thereof content of the request command which is transmitted 
5 thereto by itself In step SDl 1, the portal 7a recognizes a request of transmission of a 
request command for examination of the path information to the adjacent portal. In 
step SDl 2, the portal 7a transmits a response command INTERIM to the portal (i.e., 
portal 7a itself) that issues the request command. Then, the flow proceeds to step 
SDl 3a in which the portal 7a receives the response command INTERIM being 

10 transmitted thereto by itself In step SDl 3b, the portal 7a waits for a next response 
command to be transmitted thereto. 

In step SDH shown in FIG. 20, the portal 7a transmits to the adjacent portal 
7b a request command requesting examination on the communication path extending 
to the receiving bus. Herein, the bus ID of the receiving bus is set in an operand field 

15 of the transmitting request command. Upon receipt of the request command from the 
portal 7a, the portal 7b proceeds to steps SDl to SD3 shown in FIG. 19, so that the 
portal 7b transmits a response command INTERIM to the portal 7a. So, the portal 7a 
receives the response command INTERM from the portal 7b in step SD15. In step 
SDl 6, the portal 7a waits for a next response command to be transmitted thereto. 

20 Meanwhile, the portal 7b proceeds to step SD4 after transmission of the 

response command INTERIM to the portal 7a. At this time, a bus ID of a bus lb of 
the portal 7b does not match with the bus ID of the receiving bus, hence, the portal 7b 
proceeds to a series of steps SD5 to SD9. In step SD9, the portal 7b transmits to the 
portal 9a a request command requesting transmission of a request command for 

25 examination on the communication path extending to the receiving bus to its adjacent 
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portal. Upon receipt of the aforementioned request command from the portal 7b, the 
portal 9a proceeds to a series of steps SDIO to SD14 shown in FIG. 20. In step SD14, 
the portal 9a transmits to its adjacent portal 9b a request command requesting 
examination on the communication path extending to the receiving bus. 
5 Upon receipt of the aforementioned request command from the portal 9a, the 

portal 9b proceeds to steps SDl to SD3 so as to transmit a response command 
INTERIM to the portal 9a. Thus, the portal 9a receives the request command 
INTERIM from the portal 9b in step SD 1 5 . In step SD 1 6, the portal 9a waits for a 
next response command to be transmitted thereto. After completion of steps SDl to 

10 SD3, the portal 9b proceeds to step SD4 wherein a bus ID of a bus id of the portal 9b 
matches with the bus ID of the receiving bus. Hence, the portal 9b transmits a 
response command ACCEPTED to the portal 9a in step SD26. Herein, an operand 
field of the response command describes a node ID of the portal 9b itself 

Thus, the portal 9a receives the response command from the portal 9b in step 

1 5 SD17. In step SD18, a decision is made as to whether the received response 
command corresponds to 'ACCEPTED' or not. If 'ACCEPTED', namely, if a 
decision resuU of step SDl 8 is "YES", the flow proceeds to step SDl 9 in which the 
portal 9a transmits a response command ACCEPTED to the portal 7b that previously 
transmits the response command INTERIM (see step SD3) thereto, then, the portal 

20 process is ended. Incidentally, the portal 9a repeatedly describes content of the 
operand field of the foregoing response command ACCEPTED transmitted thereto 
from the portal 9b in an operand field of the response command ACCEPTED to be 
transmitted to the portal 7b in step SDl 9. If the received response command does not 
correspond to 'ACCEPTED', namely, if a decision result of step SDl 8 is "NO", the 

25 flow proceeds to step SD20 in which the portal 9a transmits a response command 
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REJECTED to the portal 7b, then, the portal process is ended. 

Thus, the portal 7b receives the response command from the portal 9a in step 
SD21 (see FIG. 19). In step SD22, a decision is made as to whether the received 
response command corresponds to 'ACCEPTED' or not. If 'ACCEPTED', namely, if 
5 a decision result of step SD22 is "YES", the flow proceeds to step SD23 in which the 
portal 7b provides a response command ACCEPTED whose operand field additionally 
describes a node ID of the portal 7b itself in addition to content of the operand field of 
the response command ACCEPTED transmitted thereto from the portal 9a. In step 
SD24, the portal 7b transmits such a response command ACCEPTED to the portal 7a 

10 that previously transmits the response command INTERIM (see step SD12), then, the 
portal process is ended. If the received response command does not cortespond to 
'ACCEPTED', namely, if a decision result of step SD22 is "NO", the flow proceeds to 
step SD25 in which the portal 7b transmits a response command REJECTED to the 
portal 7a, then, the portal process is ended. 

15 Thus, the portal 7a receives the response command from the portal 7b in step 

SD17 shown in FIG. 20. Then, the flow proceeds to step SD18 in which a decision is 
made as to whether the received response command cortesponds to 'ACCEPTED' or 
not. If 'ACCEPTED', the flow proceeds to step SD19 in which the portal 7a 
transmits a response command ACCEPTED to the portal 7a by itself If the received 

20 response command does not correspond to 'ACCEPTED', the flow proceeds to step 
SD20 in which the portal 7a transmits a response command REJECTED. Thus, the 
portal 7a receives the response command from the portal 7a by itself in step SD21 
shown in FIG. 19. In step SD22, a decision is made as to whether the received 
response command corresponds to 'ACCEPTED' or not. If 'ACCEPTED', the portal 

25 7a proceeds to steps SD23 and SD24 in which the portal 7a transmits a response 
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command to the IEEE 1394 device 5d, then, the portal process is ended. If the 
received response command does not correspond to 'ACCEPTED', the portal 7a 
proceeds to step SD25, then, the portal process is ended. 

As a result, the IEEE 1394 device 5d receives response packets to read 
5 contents of their operand fields. That is the IEEE 1394 device 5d obtains node IDs of 
all portals that are used for path-constructing buses to construct parts of the 
communication path. 

Incidentally, if a decision result of the foregoing step SD4 is "YES", the flow 
proceeds to step SD26. 

10 [Securement of Bandwidth and Channel in Path-Constructing Bus] 

In order to secure a bandwidth and a channel for a path-constructing bus, the 
IEEE 1394 device 5d refers to a communication path management table to check 
whether a node ID of a portal presently secured for a communication path is described 
in connection with EUI-64 information and an oPCR number of a transmitting node or 

1 5 not. If the node ID of the portal is described in connection with the EUI-64 
information and oPCR number of the transmitting node, a value of a connection 
counter of the portal is being incremented by T. If not, a node ID of a newly 
secured portal is set in the communication path management table such that a value of 
high-order ten bits is described in a bus ID field and a value of low-order six bits is 

20 described in a portal physical ID field. In this case, a connection counter field is set 
to'l'. 

FIG. 21 shows an example of a communication path management table whose 
content is being updated. After completion of updating, the IEEE 1394 device 5d 
compares a previous content of the communication path management table with an 
25 updated content of the communication path management table. Through comparison, 



the IEEE 1394 device 5d extracts from the communication path management table a 
newly added portion to specify a bus ID of the new portal stored therein. In the 
present description, no communication path is established in advance, hence, bus IDs 
being specified are '0', '1' and '3' respectively. Thus, the IEEE 1394 device 5d 
5 proceeds to securement of a bandwidth and a channel with respect to an IRM of each 
of the buses whose IDs are being specified. At completion of securement of 
bandwidths and channels with respect to all buses, the IEEE 1394 device 5d describes 
in a channel field FES of the communication path management table numbers of the 
channels being secured for the buses respectively. 

10 If the IEEE 1394 device 5d fails to secure the bandwidth and channel, the 

connection counter of the communication path management table is decremented by 
' r . Due to decrement, if a value of the connection counter is decreased to '0' while a 
certain value is still set in the corresponding channel field FES, the IEEE 1394 device 
Sd proceeds to release of the bandwidth and channel with respect to the IRM of the 

1 S corresponding bus. Then, the IEEE 1394 device Sd proceeds to setting of an SCR of 
each prescribed portal that is used as a part of the communication path. Herein, the 
communication path management table describes a prescribed value in a routing field 
FE7 with respect to each prescribed portal which is specified by a bus ID field FES and 
a portal physical ID field FE4. Thus, a request command requesting setting of an 

20 SCR is transmitted to each prescribed portal. 

The request command has an operand field that describes prescribed channel 
numbers, namely, ' 1 ' representing a channel secured on the bus lb of the portal 7b and 
'3 ' representing a channel secured on the bus la of the portal 7a, for example. Upon 
receipt of the request command, the portal proceeds to setting of an SCR. Herein, the 

25 portal does not only set an SCR thereof but also sets an SCR for an adjacent portal. 
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After completion of the SCR setting, the portal transmits a response command 
ACCEPTED whose operand field describes a number of the SCR being set. Thus, 
the IEEE 1394 device 5d extracts from the operand field of the response command 
ACCEPTED the SCR number, which is being transferred to the communication path 
5 management table thereof 

After completion of the SCR setting, the IEEE 1394 device 5d sets an oPCR 
of the IEEE 1394 device 3b corresponding to the transmitting node and also sets an 
iPCR of the IEEE 1394 device 6b corresponding to the receiving node with reference 
to the channel numbers being secured on the buses la and Id. After completion of 

10 the setting, the IEEE 1394 device 3b starts transmission of isochronous stream packets, 
so the IEEE 1394 device 6b is capable of receiving the stream packets being 
transmitted thereto. 

[Addition of Receiving Node] 

Next, a description will be given with respect to addition of a new receiving 

15 node for receiving stream packets being transmitted thereto from a transmitting node. 
The description is made with reference to the data network of FIG. 1 in which 
communication using stream packets is performed between an IEEE 1394 device 3b 
corresponding to the transmitting node and an IEEE 1394 device 6b corresponding to a 
receiving node, wherein an IEEE 1394 device 5c is added as a new receiving node. 

20 In the above, an IEEE 1394 device 5d acts as a device controller that proceeds 

to establishment of communication paths. At first, the IEEE 1394 device 5d 
transmits to a portal 7a of a transmitting bus la a request command requesting 
examination on a path-constructing bus that constructs a part of the communication 
path. Herein, an operand field of the request command describes a bus ID (namely, 

25 '2') of a receiving bus Ic. Upon receipt of the request command of the IEEE 1394 



59 

device 5d requesting examination on the path-constructing bus, each of portals 7a, 7b 
proceeds to a series of steps SDl to SD4 and SD26 shown in FIG. 19. In addition, 
each of portals 7a, 8a proceeds to a series of steps SDIO to SD20 shown in FIG. 20. 
Thus, the portals transmits to the IEEE 1394 device 5d response commands 
5 ACCEPTED indicating node IDs of prescribed portals that are used as parts of the 
communication path extending to the receiving bus. Thus, the IEEE 1394 device 5d 
secures the prescribed portals in connection with the communication path. 

Then, the IEEE 1394 device 5d refers to a communication path management 
table thereof to check whether each of the node IDs of the prescribed portals being 

10 secured is described in connection with EUI-64 information and an oPCR number of 
the transmitting node or not. If a certain node ED of the prescribed portal is described 
in connection with the EUI-64 information and oPCR number of the transmitting node, 
a value of a corresponding connection counter field is incremeted by ' 1 '. If no node 
IDs are described in connection with the EUI-64 information and oPCR number of the 

15 transmitting node, the IEEE 1394 device 5d updates the communication path 

management table thereof in response to a node ID of a newly secured portal such that 
a value of high-order ten bits is described in a bus ID field and a value of low-order six 
bits is described in a portal physical ID field. In addition, a corresponding connection 
counter field is set to ' 1'. After completion of updating, the IEEE 1394 device 5d 

20 compares a previous content of the communication path management table with an 

updated content of the communication path management table. Through comparison, 
the IEEE 1394 device 5d extracts fi-om the communication path management table an 
updated portion to specify a bus ID of the new portal stored therein. In this case, the 
IEEE 1394 device newly specifies a portal 8b. 

25 The IEEE 1394 device 5d proceeds to securement of bandwidths and channels 
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with respect to ERMs of the buses being specified respectively. After completion of 
the securement of the bandwidths and channels on all the buses, channel numbers of 
the channels being secured for the bues are transferred to the channel field of the 
communication path management table. If the IEEE 1394 device 5d fails to execute 
5 the securement of bandwidths and channels for the buses, it decrements values of the 
connection counter field of the communication path management table by ' T in 
connection with the buses. Due to decrement, a value of the connection counter field 
is decremented to '0' with respect to a certain bus, which is still connected with a 
certain channel number whose value still remains in the channel field. If such a 

10 certain bus exists among the buses, the IEEE 1394 device 5d proceeds to release of the 
bandwidth and channel on the IRM of such a certain bus. 

Next, the IEEE 1394 device 5d proceeds to SCR setting with respect to each 
of portals being used as parts of the communication path. In the communication path 
management table, each of the buses is specified by values described in the bus ID 

15 field and portal physical ID field. Among those portals, the IEEE 1394 device 5d 
transmits a request command requesting the SCR setting to each of portals for which 
routing information is described in the routing field of the communication path 
management table. Thus, the IEEE 1394 device 5d receives response commands 
from all the portals on which the SCR setting is made. If the IEEE 1394 device 5d 

20 receives response commands ACCEPTED from all the portals, it proceeds to setting of 
an iPCR of the IEEE 1394 device 5c corresponding to the new receiving node to be 
added. If the IEEE 1394 device 5d receives from the portals response commands 
other than 'ACCEPTED', it deletes information regarding the portal 8b newly 
specified from the communication path management table. After completion of the 

25 setting of the iPCR of the IEEE 1394 device 5c, the IEEE 1394 device 5c is able to 
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receive stream packets being transmitted thereto from the IEEE 1394 device 3b 
corresponding to the transmitting node. 
[Disconnection of Communication Path] 

Next, a description will be given with respect to processes for disconnection 
5 of communication paths which are established in advance. The description is made 
with reference to the data network of FIG. 1 in which communication paths are 
established in advance between an IEEE 1394 device 3b and IEEE 1394 devices 5c, 6b 
respectively, wherein a communication path being established between the IEEE 1394 
devices 3b and 5c is to be disconnected. 

10 First, an IEEE 1394 device 5d (namely, device controller) that proceeds to 

disconnection of the communication path refers to a communication path management 
table stored therein to specify portals that construct parts of the communication path 
established between the IEEE 1394 devices 3b and 5c. Namely, the IEEE 1394 
device 5d specifies portals 7a, 8a, 8b and 9b. Then, the IEEE 1394 device 5d updates 

15 content of the communication path management table by decrementing each of values 
which are described in the connection counter field in connection with the specified 
portals respectively by ' 1'. With reference to an updated content of the 
communication path management table, the IEEE 1394 device 5d specifies a bus ID of 
a bus for which a value of the connection counter field is decremented to '0'. In this 

20 case, the BEEE 1394 device 5d specifies the portal 8b. 

That is, the IEEE 1394 device 5d specifies a bus Ic corresponding to a bus ID 
which is described in the bus ID field in connection with the value '0' of the 
connection counter field. So, the IEEE 1394 device 5d proceeds to release of a 
bandwidth and a channel with respect to an IEEE 1394 device 5 a which is an IRM of 

25 the bus Ic being specified. Then, the IEEE 1394 device 5d transmits a request 
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command of clearing SCR setting to the portal (namely, 8b) which is listed in the 
communication path management table in connection with the value '0' of the 
connection counter field. 

An operand field of the aforementioned request command describes a number 
5 of an SCR to be cleared. The portal 8b reads content of the request command from a 
command area thereof so as to recognize a request of clearing the SCR setting thereof 
Then, the portal 8b itself and its adjacent portal 8a clear the SCR setting with respect 
to the SCR number. After completion of the aforementioned processes, the portal 8b 
transmits a response command ACCEPTED. Upon receipt of the response command 

10 ACCEPTED from the portal 8b, the IEEE 1394 device 5d recognizes that 

disconnection of the communication path is completed. Then, the IEEE 1394 device 
5d deletes information regarding the value '0' of the connection counter field from the 
communication path management table. Thus, the IEEE 1394 device 5d clears 
setting of an iPCR of the IEEE 1394 device 5 c. 

15 [Bus Reset on Path-Constructing Bus] 

An IEEE 1394 device (e.g., 5d) that controls communication paths proceeds 
to transmission of prescribed request commands at completion of establishment of the 
communication paths. Namely, with reference to a communication path management 
table shown in FIG. 18, the IEEE 1394 device transmits to all portals, which are 

20 specified by values described in a bus ID field FE3 and a portal physical ID field FE4, 
request commands that request the potals to make communications upon detection of 
bus resets. Thus, the portals receiving the aforementioned request commands make 
communications by transmitting response packets therefrom when detecting bus resets 
respectively. Due to the communications, the IEEE 1394 device for controlling the 

25 communication paths recognizes occurrence of the bus resets and proceeds to re- 
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securement of bandwidths and channels. 

Next, a concrete description is given with respect to re-securement of 
bandwidths and channels under control of the IEEE 1394 device for controlling 
communication paths. The description is made with reference to the data network 
shown in FIG. 1 in which communication paths are established in advance between an 
IEEE 1394 device 3b and IEEE 1394 devices 5c, 6a respectively, wherein bus reset 
occurs on a bus lb, for example. After occurrence of the bus reset, a transmitting 
node and receiving nodes remain being connected with the data network. At 
occurrence of the bus reset on the bus lb, a portal 7b makes a communication to an 
IEEE 1394 device 5d for controlling the communication paths. Upon receipt of the 
communication, the IEEE 1394 device 5d refers to a communication path management 
table thereof to extract a value of a bandwidth field and a value of a channel field 
which are described in connection with a bus ID of the bus lb and a physical ID of the 
portal 7b. Based on the extracted values, the IEEE 1394 device 5d proceeds to re- 
securement of a bandwidth and a channel with respect to an IEEE 1394 device 4b 
which is an IRM of the bus lb. In response to results of the re-securement, the IEEE 
1394 device 5d proceeds to different processes, which will be described below with 
regard to three cases. 

(1) First case where the IEEE 1394 device 5d succeeds to re-secure the bandwidth 
and channel. 

In this case, the IEEE 1394 device 5d refers to a value of the bus ID field which 
is described in connection with the physical ID of the portal physical ID field 
representing the portal (i.e., 7b) which makes a communication notifying occurrence of 
the bus reset. Thus, the IEEE 1394 device 5d checks whether such a value of the bus 
ID field matches with either a bus ID of a transmitting bus or a bus ID of a receiving 
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bus or not. If the value matches with the bus ID of the transmitting bus, the IEEE 
1394 device 5d makes again setting of an oPCR of a transmitting node, then, the 
process is ended. If the value matches with the bus ID of the receiving bus, the IEEE 
1394 device 5d makes again setting of an iPCR of a receiving node, then, the process 
is ended. If the value does not match with both of the bus IDs, the IEEE 1394 device 
5d immediately ends the process thereof 

(2) Second case where the IEEE 1394 device 5d succeeds to re-secure the bandwidth 
and channel, whereas a re-secured channel number differs from a previous 
channel number previously secured prior to occurrence of the bus reset. 
The IEEE 1394 device 5d updates the communication path management table by 
changing a value of the channel field, which is described in connection with the portal 
7b, with a new value designating the re-secured channel number. Then, the IEEE 
1394 device 5d requests the portal 7b to update its SCR setting in response to the re- 
secured channel number. Upon receipt of a response command declaring that the 
portal 7b completes updating the SCR setting, the IEEE 1394 device 5d refers to a 
value of the bus ID field, which is described in connection with the physical ID of the 
portal physical ID field representing the portal (i.e., 7b) making a communication 
indicating occurrence of the bus reset, in the communication path management table. 
Then, the IEEE 1394 device 5d checks whether such a value of the bus ID field 
matches with either the bus ID of the transmitting bus or bus ID of the receiving bus or 
not. If the value matches with the bus ID of the transmitting bus, the IEEE 1394 
device 5d performs again setting of the oPCR of the transmitting node, then, the 
process is ended. If the value matches with the bus ID of the receiving bus, the IEEE 
1394 device 5d makes again setting of the iPCR of the receiving node, then, the 
process is ended. If the value does not match with both of the bus IDs, the IEEE 
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1394 device 5d immediately ends the process thereof. 
(3) Third case where the ffiEE 1394 device 5d fails to re-secure the bandwidth or 
channel. 

With reference to the communication path management table, the IEEE 1394 
device 5d extracts a value ('2') of a connection counter field and a value (namely, a 
node ID of the portal 7a) of a routing field, which are stored in connection with the bus 
ID of the bus on which bus reset occurs. Then, the IEEE 1394 device 5d specifies a 
value ('0') of a bus ID field that matches with high-order ten bits of the extracted value 
of the routing field. So, the IEEE 1394 device 5d decreases a value of a connection 
counter field, which is stored in connection with the specified value of the bus ID field, 
by the foregoing value of the connection counter field being previously extracted. 
Thus, the IEEE 1394 device 5d updates each of fields concerned with the connection 
counter field whose value is decreased. Thereafter, the IEEE 1394 device 5d newly 
extracts a value of a routing field which is stored in connection with the 
aforementioned fields being updated. So, the IEEE 1394 device 5d specifies a value 
of a bus ID field that matches with high-order ten bits of the newly extracted value of 
the routing field. Thus, the IEEE 1394 device 5d repeats the aforementioned 
processes. 

If the IEEE 1394 device 5d fails to extract a value of a routing field to which 
no value is set in advance, the IEEE 1394 device 5d designates another routing field 
corresponding to a node ID of a specific portal (namely, a node ID of the portal 7b) 
which is specified in response to a portal physical ID described in connection with a 
bus ID of a bus that detects bus reset. Then, the IEEE 1394 device 5d sets a value of 
a connection counter field, which is stored in connection with a value of the designated 
routing field, to '0'. Thus, the IEEE 1394 device 5d updates each of fields concerned 
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with the connection counter field whose value is set to '0'. Then, the IEEE 1394 
device 5d designates a routing field corresponding to a node ID of a portal that is 
specified by a value of a bus ID field and a value of a portal physical ID field which 
are stored in connection with the aforementioned fields being updated. Thereafter, 
5 the IEEE 1394 device 5d ends the process thereof 

If the IEEE 1394 device 5d fails to designate the routing field, the IEEE 1394 
device 5d refers to the communication path management table thereof to extract a 
value of a bus ID field which is stored in connection with a specific connection counter 
field whose value is '0'. Then, the IEEE 1394 device 5d proceeds to release of a 

1 0 bandwidth and a channel on an IRM of a bus to which a bus ID corresponding to the 
extracted value of the bus ID field is being allocated. The IEEE 1394 device 5d 
repeats the aforementioned process on all buses whose bus IDs are stored in 
connection with the connection counter field whose value is '0'. At completion of 
the process with regard to all buses, the IEEE 1394 device 5d sets a value of the 

1 5 connection counter field, which is stored in connection with the bus ID of the bus on 
which bus reset occurs, to '0'. Lastly, the IEEE 1394 device 5d discards all 
information data which are stored in connection with the connection counter field 
whose value is '0', then, it ends the process thereof 

According to the second embodiment described above, the IEEE 1394 device 

20 for controlling communication paths is used to perform securement of bandwidths and 
channels on path-constructing buses. This simpHfies portal processes being executed 
by portals. In addition, the IEEE 1394 device for controlling communication paths 
concentrates all pieces of information used for management of the communication 
paths therein. If the data network is configured using plural IEEE 1394 devices each 

25 of which is capable of controlling communication paths, it is possible to perform 



transactions of management information between those devices with ease. 

The aforementioned embodiments describe examples of communication path 
control devices. Of course, this invention is not necessarily limited to those 
embodiments, so it is possible to arbitrarily change designs of the devices within the 
scope of this invention. The aforementioned embodiments are described exclusively 
with respect to applications of the IEEE 1394 standard. However, this invention is 
applicable to any types of communication path control devices that are capable of 
performing serial bidirectional communications using packets and that are connectable 
with any types of buses for connecting together multiple audio/visual devices or else. 

As described heretofore, this invention has various technical features and 
effects, which are described below. 

(1) Portals are designed to perform securement of bandwidths and channels as well 
as SCR setting in a data network configured by interconnections of buses by 
means of bridges. Hence, each ffiEE 1394 device (or each node) for controlling 
communication paths is not required to consider topology of the data network. 

In addition, each portal proceeds to restoration of a path-constructing bus on 
which bus reset occurs. Thus, each node for controlling communication paths 
is not required to monitor occurrence of the bus reset on the path-constructing 
bus. 

(2) If each IEEE 1394 device for controlling communication paths is designed to 
perform securement of bandwidths and channels, it is possible to simplify portal 
processes being executed by the portals. In addition, the IEEE 1394 device for 
controlling communication paths concentrates all pieces of information used for 
management of the communication paths therein. Hence, if the data network 
contains plural IEEE 1394 devices each of which controls communication paths, 
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it is possible to perform transactions of management information between those 
devices with ease. 

As this invention may be embodied in several forms without departing from 
the spirit of essential characteristics thereof, the present embodiments are therefore 
illustrative and not restrictive, since the scope of the invention is defined by the 
appended claims rather than by the description preceding them, and all changes that 
fall within metes and bounds of the claims, or equivalence of such metes and bounds 
are therefore intended to be embraced by the claims. 



